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
Bug 1131726 - Data from RHQ_CONFIG_UPDATE never purged

Remove old resource config and group resource config updates from the
database.

The configuration and configuration properties entities get removed as
well.

An old config update may stay in the database if it is the last successful one.

An old group config update may stay in the database if one of the
children config update is the last succesful one for the target resource.
Include rhqapi.js as CLI module
Bug 1162293 - Unable to reverse proxy traffic to JON UI

Got rid of _ in RHQ specific HTTP header names, so when running behind
nginx, directive underscores_in_headers on; is on longer required
Merge pull request #146 from lzoubek/master

Include rhqapi.js as CLI module
Bug 1119802 - RFE: Support for resource type name change

Added displayName optional attribute to resource type. This does allow to
change resource type name (by specifying this attribute in plugin
descriptor) and at the same time does not require to drop & re-create whole
resource type on server when performing plugin upgrade. I've updated all
coregui code, to show displayName instead of just name, legacy gui was not
updated as it is no long used.
Merge pull request #98 from lzoubek/bugs/1119802

Bug 1119802 - RFE: Support for resource type name change
Merge branch 'purgepurgepurge' of https://github.com/tsegismont/rhq into tsegismont-purgepurgepurge

Conflicts:
	modules/core/dbutils/src/main/scripts/dbupgrade/db-upgrade.xml
	modules/enterprise/gui/coregui/src/main/resources/org/rhq/coregui/client/Messages_de.properties
	modules/enterprise/gui/coregui/src/main/resources/org/rhq/coregui/client/Messages_ja.properties
	modules/enterprise/gui/coregui/src/main/resources/org/rhq/coregui/client/Messages_ru.properties
Bug 1133590 - Unable to login in to 'Red Hat Access' in IE

revert commit b333a0250
Bug 1133590 - Unable to login in to 'Red Hat Access' in IE

    finish reverting commit b333a0250 - semicolon removed
Merge branch 'tsegismont-purgepurgepurge'
[BZ 1160775] - RFE Adding a way to show/hide RHQ subsystems in UI

Current UI is overcomplicated. RHQ does lots of things and
different users use it for different purposes. Although many
subsystems are interconnected and may depend on each other
(e.g. metrics and alerts). This is not the case for all of them
and in the sake of simplicity some of them could be hidden in
UI if user wants to.

This PR allows to hide following subsystems/features in UI:
 * content
 * reports
 * administration
 * events
 * operations
 * alerts
 * config
 * drift

NOTE: This change is only about hiding it in UI, the subsystems
are still working and can be acessed via REST, CLI or direct
URL.

The subsystems can be shown/hidden on the user page
${host}/coregui/#Administration/Security/Users/${userId}
and this information is saved to the user preferences.

It is orthogonal to the access rights that are specified for
roles. Each user may decide what to hide to make the UI
cleaner for him/her.
[BZ 1160775] - RFE Adding a way to show/hide RHQ subsystems in UI - fixing FF issues and changing the switches according to UX proposal
[BZ 1160775] - RFE Adding a way to show/hide RHQ subsystems in UI - i18n and improving CSS for the switches
[BZ 1160775] - RFE Adding a way to show/hide RHQ subsystems in UI - rewriting it to use the bootstrap-switch library; messages