This is an interim solution for supporting HSM failover by automatically
shutting down the server when signing key becomes inaccessible.
At auto-shutdown, a crumb fiile will be left in the instance directory
for an external daemon to detect and restart, if necessary.
Due to limitation of the watch dog (nuxwdog) at present time,
the restart option currently only works if started with watch dog (nuxwdog),
and it will prompt for passwords on the terminals.
The restart counter is to prevent the server from going into an infinite restart
loop. Administrator will have to reset autoShutdown.restart.count to 0 when max
is reached.

(cherry picked from commit 5a9ecad9172f76ca1b94b40aedcdd49d009aceb1)

We currently disable the cert status maintenance thread on
clone CAs because CRL processing should only be done on the
master CA.  Currently, the maintenance thread also performs
other checks on serial number ranges and settings.  By disabling
the maintenance thread, we disable these checks too.

To fix this, we have separated the serial number checks into a
different maintenance thread, so that these tasks will occur
even if the cert status thread is disabled.

Bugzilla # 1251606

(cherry picked from commit d3d80046fd6985b809900005a685695d3181d9d3)

The HttpConnection class has been modified to support fail-over
and timeout more consistently. The targets are parsed into a list
during initialization. All direct calls to HttpClient.connect()
are replaced with a method that will connect to the first available
target. All connections are now created with a timeout (which by
default is 0).

https://fedorahosted.org/pki/ticket/891

Addresses the complaint of this ticket. Tested to work in a few basic cases. The minor code change
was designed to only affect the specific scenario when we have a daily scedule that spans only one day.

More Info:

How to duplicate and test:

    Perform a manual crl generate from the agent interface because the code to be tested relies heavily upon the "lastUpdate" which will appear in the logs. Do this to have a nice launching off point.

    Go to the ca's pkiconsole and select : Certificate Manager -> CRL Issuing Points -> MasterCRL.
    Check "updateCRL at: " and give a schedule such as : 15:03, 15:10 .. This gives us a chance to watch the two regularly scheduled updates happen.

    When the first event triggers, have a look at the CA's "debug" log and note the following or similar entry:

[CRLIssuingPoint-MasterCRL]: findNextUpdate: Wed May 06 15:10:00 PDT 2015 delay: 86301873

    Wait for the 15:00 even to happen. When that triggers at the end of that cycle, we should see one more similar entry.

[CRLIssuingPoint-MasterCRL]: findNextUpdate: Wed May 06 15:03 PDT 2015 delay: 86301873

That is the correct behavior after the fix. We want the next update to be at the first entry of the daily schedule , but tomorrow. The current bug would print out this value as something like:

    Wed May 06 00:00:00 or similar to indicate midnight. This is not what we want.

The REST service classes have been moved into org.dogtagpki.server
namespace. A new upgrade script has been added to update existing
instances.

Ticket #114

New ACL has been added to allow only the administrators to access
TPS authenticators.

The set of interceptors in each application has been modified to
preserve the order.

Ticket #652

Due to a regression RESTEasy is unable to find some sub-resources properly.
As a workaround some resources need to be merged into the parent resource.
The UserCertResource and UserMembershipResource have been merged into
UserResource. The GroupMemberResource has been merged into GroupResource.

A new REST service and clients have been added to manage the audit
configuration in all subsystems.

Ticket #652

New REST service and clients have been added for managing selftests
in all subsystems.

Ticket #652