BZ 991510 - Add method javadoc
[BZ 1070521] Fixed retrieval of OOB datapoints.
[BZ 1149687] - Storage Node's cluster status is DOWN when cluster maintenance is scheduled - considering the MAINTENANCE operation mode as NORMAL cluster status.
[BZ 1114600] - Cannot load Metric red error when client time is different from server - trying to resolve the time into # of milliseconds on the server side where the referential time zone is used. Introducing a new class called Moment for storing 5 integers: year, month, day, hours, minutes.
[1151441] JON server was unexpectedly stopped
Only resolve the identity of the running server (i.e. the SERVER_NAME) one
time and cache it as a static for ServerManagerBean.  This is more efficient
as the server name can not change at runtime, and actually should not change
for a defined server, ever, in general.  Moreover, for server where
rhq.server.high-availability.name is not set, it prevents repeated calls to
InetAddress.getLocalhost(), which can fail if there is a temporary DNS
issue, and the localhost can not be resolved.
[BZ 1114600] - Cannot load Metric red error when client time is different from server - Moving Moment.java to core/domain module. There was CNF exception during the install, but also CLI can benefit from this timezone independent class as well. (because depending on number millis from 1970 is confusing - it may return different number on different timezones)
[BZ 1114600] - Cannot load Metric red error when client time is different from server - Renaming Moment.java -> Instant.java to be 'language compliant' with Joda time and Java 8 time API.
itests-2 were broken beacuse Server and StorageNode entities now have a version column
[BZ 1114600] - Bulk revert of 3448429138161, cb5078b367f9e and 546cf53e3c588 - I reproduced the issue by changing the time on a client (browser) machine. But we don't support such a behavior. When changing only the timezone, I didn't reproduce the exception.

* Revert "[BZ 1114600] - Cannot load Metric red error when client time is different from server - Renaming Moment.java -> Instant.java to be 'language compliant' with Joda time and Java 8 time API."

This reverts commit 3448429138161a1fd329b3f937488ee65fd9a199.

* Revert "[BZ 1114600] - Cannot load Metric red error when client time is different from server - Moving Moment.java to core/domain module. There was CNF exception during the install, but also CLI can benefit from this timezone independent class as well. (because depending on number millis from 1970 is confusing - it may return different number on different timezones)"

This reverts commit cb5078b367f9ed8d268669fbdc122422e08dfa19.

* Revert "[BZ 1114600] - Cannot load Metric red error when client time is different from server - trying to resolve the time into # of milliseconds on the server side where the referential time zone is used. Introducing a new class called Moment for storing 5 integers: year, month, day, hours, minutes."

This reverts commit 546cf53e3c58825ca089aa90e49f1897de937887.
Bug 1074633 - RFE: Manage storage node snapshots

Fix StorageNodeComponentItest - basically our tests were running too fast.
Failures happened beause of fact, that lastModified file attribute is stored
in seconds - so our tests tended to generate several snapshots within same
second and that led to incorrect behavior of tested "takeSnapshot"
operation. Several console logging has also been added.
changes. Lines starting
Fix core domain tests and server itests when database does not have Server and StorageNode version columns

Version columns are not created as part of the db-upgrade process, but only when running the installer.
So we need something when running itests or core domain tests against an upgraded database.
Move purge settings to a new "Advanced Purge Settings" group (hidden by default)
Bug 1145776 - RHQ_PARTITION_EVENT data not purged automatically

Added partition event and partition event details purge
It's disabled by default and configurable through System Settings.

Added partition event test in DataPurgeJobTest

Also, refactoring DataPurgeJob and DataPurgeJobTest
Bug 1139433 - Deadlock in deletion of RHQ_RESOURCE_ERROR, possibly in resource upgrade?

When saving a resource error, we first delete existing errors if the error type is one of:
* INVALID_PLUGIN_CONFIGURATION
* AVAILABILITY_CHECK
* UPGRADE
I'm not sure why we don't if the error type is DISABLED_TYPE.

The goal is to keep only one copy of these error types.

Here's my analysis of the deadlock report attached to the BZ.

Due to the type of locks (row locks) and the queries involved, it looks like the deadlock is the consequence of concurrent calls to ResourceManagerBean#clearResourceConfigErrorByType with the same parameters. Such concurrent calls would not necessarily lead to a deadlock. It would happen only if the row locking order is different. My knowledge of Oracle is limited but I'd say this is possible if the two queries get a different execution plan. I tried to figure out why the same query could lead to a different execution plan and one possible reason would be that one is using the index on resourceId and the other one is not.

This commit addresses the issue by changing the way previous errors are deleted. Now before delete we select an ordered list of primary keys. Then we delete the rows by primary key. Consequently, two competing sessions will never lock rows in different orders.

There's another issue due to the way resource errors are implemented. Two competing sessions will delete previous errors but both will insert a row. A DataPurgeJob task has been added to remove such duplicates, if any.
Bug 1139433 - Deadlock in deletion of RHQ_RESOURCE_ERROR, possibly in resource upgrade?

I checked Git history. From the looks of it, DISABLED_TYPE was added later in the game.
To me there's no reason why we let more than DISABLED_TYPE error per resource be persisted.
Bug 1145778 - Purge RHQ_RESOURCE_ERROR table as well

The fix for "Bug 1139433 - Deadlock in deletion of RHQ_RESOURCE_ERROR, possibly in resource upgrade?" enforces "only single error of a type for a given resource".

This change is to clear stale AVAILABILITY_CHECK errors (if a resource AVAIL is up, then there's no need to keep the resource error)

* INVALID_PLUGIN_CONFIGURATION -> auto cleaned when the agent starts the resource container.
* UPGRADE -> we need to keep it to inform the user
* DISABLED_TYPE -> we need to keep it to inform the user