updating descriptions of (un)deployment storage node resource operations
Fix OperationManagerBean: parameters should be copied in ResourceOperationHistory
obfuscate rhq.storage.password

In RHQ 4.8, we had rhq.cassandra.username and rhq.cassandra.password. These
been replaced with rhq.storage.username and rhq.storage.password. The
password property needs to be obfuscated like the relational database password.
If you set rhq.storage.password to an obfuscated string, the upgrade command
was replacing it with the plain-text value of rhq.cassandra.password. Since
the username/password was hard-coded as rhqadmin/rhqadmin in 4.8, we can safely
set rhq.storage.password to the obfuscated string.
BZ 988735 - refine the callback API. Abort the discovery of a specific resource if more than one callback processed the details. added integration test to see it work
Ensure console objects don't cause problems in IE.  In CoreGUI.html there is a js IFFE that should take care of defining an undefined console object for IE but this snippet doesn't seem to be working yet. Will come back to this later.
[BZ 1003794] Cannot load metrics on some resources when data is not available yet.
Handle null RawNumericMetric better.
BZ 988454 - add a readme to the plugin
The small sparkline graphs displayed on in the storage node admin UI now corresponds with the actual data. There was a bug that actually caused that each row contained a graph for a different row (it was shuffled).
Update to the {Grease|Tamper}monkey script: removing the syntax warinings reported by the browser extension.
[BZ 1004319] fixing oracle dbupgrade error
Give ResourceMetadataManagerBeanTest.upgradePluginWithTypesRemoved more chances to pass on slow boxes
[BZ 1004449] fix maintenance_pending column

Adding a not-null constraint in dbupgrade and set the column when creating the
storage node during installation.
adding some debug logging

This logs the schedule id for queries which will help so that we do not have to
resort to other means of hunting down the schedule id.
Fix bug with metrics refresh firing only once.
[BZ 855674] - avoid truncating the waitTime but rather round up.

This is to avoid cummulation of rounding errors that could lead to lower
wait times than expected.
EAP5 plugin: process execution result may be null
[Bug 1003132 - Recovery alerts based on availability may not fire if AlertConditionCache isn't reloaded before next availability report]
The issue here is the lag time between processing recovery actions (like disable
of the to-be-recovered alert def, enable of the recovery alert def, etc) and
the alerting cache reloads, which can be up to 30s.  The 30s [max] time
is reasonable for other HA nodes, but for the server serving the agent, and\
firing the alert that triggers the recovery handling, it can be too long
because the recovery action (if automated, like a restart) may happen
before the cache reload, effectively missing the recovery alert.

Note that given the current architecture, which executes the alert
notifications prior to committing the alert (this should likely change),
means that the cache reload must still take place after in-band notification
processing. So, even though this fix will execute the reload as soon as
possible, it is feasible that a small window of vulnerability will still
exist if automated recovery actions are performed very quickly.

Also:
- add missing @Override annotations to related SLSBs
- add missing isDebugEnabled() protection to related SLSBs
Mostly code cleanup of storage UI, removing commented out code, better exception handling. Also making sure the polling job for fetching the actual number of unacknowledged alerts is correctly unscheduled when the page is not visible or the session has expired. Changing the label "New Alerts" to more descriptive one "Unacknowledged Alerts". On the detail page if the operation failed during the (un)deployment phase, it is explicitly mentioned that it happened during the (un)deployment.