Bug 1079546 - Postgres Plugin - Postgres.Inventory.ChildHistory - Past N Days Filter Appears To Hang With Empty Value

Use DateFilterItem instead of "Past N days" SpinnerItem
Use Countdownlatch instead of nested GWT async service calls
Handle parse error and null dates
Bug 1073991 - Create Child resource with User Type for postgres server doesn't work correct

Resource name is a mandatory property of the Create Resource Report
[1095016 - Quartz stops working if database connection is reset]
We create the NoTxRHQDS solely for use by Quartz to interact with its jobs.
The errors resulted from connections not being validated in a timely manner
by AS7/EAP.  It was hard to figure out because we needed to explicitly set
<validation>
  <validate-on-match>true</validate-on-match>
</validation>

What this flag does is a little hard to figure from its description. And
according to the EAP documentation [1] this is supposed to be true by default.
But it isn't.  EAP bug pending creation...

- added the new option to our DMR client used by the installer
- cleaned up quartz.properties a bit, organizing and removing ignored settings
- note that this is not needed on the XA DS
[BZ 1096332] Make sure ResourceContexts are fully inited on the agent

During InventoryManager initialization we do a lot of work including
activation and initialization of the resource containers and syncing
with the server for the purpose of resource activation and upgrade.

The initialization of the InventoryManager is done early in the
plugin container startup when most of the other services are not yet
available. But because we need a (sort of) functional inventory and
resource components DURING the inventory manager initialization, we
cheat a bit leaving some parts of the ResourceContext non-functional
during InventoryManager initialization. This has been made more serious
by the RFE BZ 991149 (commit 79a09a0a5a5402539f7a54668813f60ba274ce5a)
that made a lot of the initialization code more eager.

This fix is not much more but a band-aid providing a new "recovery
logic" to reinitialize all the resource containers and their resource
contexts once the initialization of all the plugin container services
is finished. This ensures proper initialization of all the parts of
the resource contexts AFTER the plugin containers is fully started up
but doesn't solve the problem of non-functional "parts" of resource
contexts during the resource upgrade phase (which is done during the
start up sequence). Granted this has not been proven to be an issue
yet, because the upgrade logic is usually very simple and doesn't
really need to access the parts of the resource context that are
affected by this (ATM I know of Content and Drift subsystems being
malfunctioning during the resource upgrade phase).

So in another words, this band-aid restores the proper functionality
from the pre-BZ-991149 days but doesn't really try to resolve the
essentially broken nature of our startup logic where we cannot really
guarantee the state of the container services (this is made worse by
the fact that the PluginContainer is a singleton to which any code
can get a reference in any stage of its lifecycle).