[BZ 970784] After successful deployment, initiate discovery scan for affected resources on the agent side.

 Add new column DEPLOYMENT_DELAY_IN_SECONDS to BundleDeployment

Add new message view_bundle_deployWizard_discoveryDelay

Allow changing the discoveryDelay from recipe (org.rhq.discoveryDelay property) as well as from the UI. If previous liveDeployment had a different value, use that one.

Allow recipe to override values also when using the CLI
Merge pull request #123 from burmanm/BZ970784

[BZ 970784] After successful deployment, initiate discovery scan for affected resources on the agent side.

Add new column DEPLOYMENT_DELAY_IN_SECONDS to BundleDeployment
Add new message view_bundle_deployWizard_discoveryDelay
Allow changing the discoveryDelay from recipe (org.rhq.discoveryDelay property) as well as from the UI. If previous liveDeployment had a different value, use that one.
Allow recipe to override values also when using the CLI
[1144459] [eap6] Warnings in agent.log - Required property 'manage' and 'delete-durable-queue' have a null value
An issue in the plugin descriptor resulted in an ill-defined configuration
definition for the 'Role' "list of maps".  Fixing the descriptor should
resolve the issue when resource config is rediscovered for an existing
resource.  New resources should be fine from the start.

Also, fix an issue in the config editor when rendering a lot of property
fields. Something that showed up after the all of the properties started
showing up.

The lesson here? Listen to your log file warnings :)
[BZ 1136998] Fix the logic in the upgrade delegate.

It now better distinguishes between configuration values coming from a
previous upgrade report in the chain versus the values coming from
the existing resource.

Being aware of the distinction is needed for a correct decision on what
value should the "supportsPatching" attribute set to.
[BZ 1114199] Make sure data expiration is consistent for late data

Raw data has a retention of 7 days. Previously if we inserted late data that
was a day old, you might expect that it would expire in 6 days; however, the
data actually expire in 7 days. This is because the TTL and column timestamp
cannot be bind variables in Cassandra 1.2.x prepared statements. This commit
fixes the problem so that the one day old data will expire in 6 days. This
is accomplished without sacrificing the use of preared statements.

A cache of prepared statements is now used. Theere is one statement for each
of the past 7 days including today. For data that is 2 days old, we will insert
using a prepared statement that has a column timestamp of today minus 2 days,
and the data will expire in 5 days.

An EJB timer tasks runs every day at 12:00 AM to remove the oldest statements
from the caches and add a new statement for tomorrow. We store an extra
prepared statement for tomorrow to deal with scenarios where data is stored
right at midnight.
[BZ 1114199] do not update insert statement caches more than once in a day