BZ1032192 - AlertCondition composite queries, query each column

Hibernate would return an empty entity and consequently lead to N+1 selects.

The code is ugly, unfortunately.

Adding tests for these queries
BZ1032192 - AlertCondition intentional API changes

Adding intentional API changes as well
Bug 1074632 - RFE: Manage storage node snapshots

2nd piece of impl above BZ. This patch adds server side capability to manage
snapshots for storage cluster. This basically means that we regularly run
takeSnaphost operation with several parameters - so user can decide whether
to keep all of them, keep last or move older ones to specified location.

6 new private/readonly system settings have been introduced - those settings
can be updated only via Storage admin pages.

User can enable/disable snapshots management of storage cluster and set cron
expression to run management task regulary (additional 4 settings are
basically parameters for takeSnapshot operation introduced within previous
commit for this BZ). When Cluster Setting is saved in UI we re-schedule
takeSnapshot operations on all StorageNode resources in inventory.

Snapshot related code was removed from
StorageNodeManagerBean#runClusterMaintenance()
[BZ 959455] - Confusing number of total rows in Administration->Agents page - calling setPagingInfo(response, result); solves the issue. I fixed that also for StorageNodeDatasource, AffinityGroupWithCountsDatasource, FailoverListItemDatasource, PartitionEventDatasource, ServerDatasource and ServerWithAgentCountDatasource
[BZ 1122512] - Missing remove_Disabled.png icon - adding the icon
[BZ 122500] - Ok and Cancel buttons are scrolled out from visible area of modal dialog - increasing the size of popup to make the buttons visible; also improving the select items.
[BZ 837449] Change behaviour of apache plugin to select ServerName + VirtualHost combination as first priority for resourceName and fall back to server address only if ServerName can not be found
[BZ 1117449] Add logging to NativeSystemInfo to detect why Java platform was selected
Bug 1041393 - alert notification of type Resource operations is not
correctly rendered by API

AlertNotificationRest extended with extraConfig field where we now output
notification extra config (in case of Resource Operations alert sender, it's
input parameters for operation)

With this commit we now also properly render alert notification config
(simple property types mapped correctly to JSON/XML, not "just" string
values)

This commit fixes ConfigurationHelper#configurationToMap which transforms
Configuration to generic Map, now it can work without Configuration
Definition
- as a fall-back it maps all simple properties to string values.
[BZ 1083479] - Second invocation of about dialog fails - creating the dialog from scratch (instead of using the cached instance that was causing the issue). Also adding a link to GitHub commit corresponding to the build number (only for RHQ).
Bug 1127264 - Creating alert notification of type Resource Operations
ignores extraConfig field
[1126853] Alert does not trigger if defined with 'disable when fired'
This was undetected fallout from the work done in BZ 1110434.  Although,
it's fallout that doesn't make a lot of sense.  It's either a bug in
HornetQ/Arjuna/EAP interaction Tx management, or we violated some very
subtle J2EE/JTA rule.  Basically this is what was happening:
1) alert condition consumer onMessage is invoked (with default CMT Tx semantics)
2) it invokes a series of nested SLSB calls with various Tx semantics, including
   REQUIRED, REQUIRES_NEW and NOT_SUPPORTED.
3) The NOT_SUPPORTED method hangs on method return, as such some downstream
   processing commits (due to REQUIRES_NEW semantics) but the upstream calls
   don't complete.  So even though the alerting all worked, it never got
   to commit.
4) After 10 minutes the Tx reaper comes along and cancels the hanging Tx.

The fix/workaround is actually easy. Instead of calling the general purpose
disableAlertDefinitions() method (which supports mass-disable and therefore
uses the NOT_SUPPORTED semantics to help chunk transactioning) we switch to
the disableResourceAlertDefinitions() method (which uses REQUIRED) because
we know we are dealing with a single resource-level alert definition.
We make an analogous change for enable.  We are basically avoiding the
issue.
Bug 1070323 - (JON3-41) JBoss ON must support JBoss Diagnostic Reporter
(JDR)

Increase JDR request timeout to 10minutes
Bug 1119240 - Adding http-interface in the host controller's host-slave.xml
is not recognised by JBoss ON Agent causing Host Controller's availability
to stay DOWN

throw InvalidPluginConfiguration exception when http mgmt interface port is
detected as 0 (not-detected). User is advised to set his host controller up
and then update connection settings.
Merge pull request #97 from lzoubek/bugs/1074632

Bug 1074632 - RFE: Manage storage node snapshots (part. 2)
BZ-1124767: Setting appropriate defaults for new properties trustStrategy and hostnameVerification introduced in BZ-1062552.

These defaults are used when the property is loaded from the resource's
plug-in configuration. This is necessary to handle situations in where a
resource was already in inventory when the new plug-in is installed.
Bug 1128141 - HostController gets DOWN when name attribute in host.xml is
empty

Fallback to detect host name using on $HOSTNAME and others in case we don't
find it in host.xml
Some unsolicited slsb code cleanup
- remove unnecessary/duplicate class level datasource annotations
- use DatabaseTypeFactory.getDefaultDatabseType() where appropriate
- add missing statement close in ResourceAvailabilityManagerBean
- use util safeClose methods as appropriate
[1127029] Agent [null] would like to connect to this server
The issue here is that 'rhqctl install' does not make provisions for an
existing agent on the machine.  When installing an RHQ Server or Storage
Node it is then expected that RHQ components be managed by the rhqctl
facility.  This is made possible when upgrading from pre-rhqctl versions
by the 'rhqctl upgrade' --from-server-dir and --from-agent-dir options,
which allow an upgrade to "pull in" the existing components on the machine.
The missing use case is this one, when not upgrading but rather installing.
So, this commit adds the --from-agent-dir option to 'rhqctl install'.
Allowing a formerly installed RHQ Agent to be updated (as needed) and
pulled under rhqctl, moving it to the expected location of sibling
directory to the rhq-server installation directory (and not installing
a new agent, which caused the reported issue)
- Also, fix an issue in 'rhqctl upgrade --from-agent-dir' where the new
  agent was not actually moved to the proper sibling directory.  I believe
  this affected RHQ 4.12 (and possibly JON 3.2)
Replacing Header Icons and fix spacing

(cherry picked from commit 1b695d390fa41ce3d4a2ad1506121468a70488e1)
Signed-off-by: Jirka Kremser <jkremser@redhat.com>