[BZ 1042828] - CallTimeDataManager manager should be able to expose raw
data, not just the aggregates

Raw data are now exposed via findCallTimeDataRawForResource. We don't return
RAW data (meaning per-request entities), because RHQ server does not store
it. Instead it stores already aggregated data - aggregation per
callDestination happens on agent when sending metric report. At maximum (as
minimum collection interval is 1m) user can get aggregated data for requests
within 1 minute per callDestination). This data are considered as RAW
because it's rawest we have.
Uses a wrapper to catch the return value instead of the ExecuteException
Remove commented lines
AS7 i-test work, fix build issue
AS7 i-test, restore ManagedServerTest to executed test classes, it was lost in a merge.
as7plugin: let MemoryPoolComponent start even if the underlying server is down

This is to avoid ugly exception logs like:

2014-03-05 09:55:17,436 ERROR [main] (rhq.core.pc.inventory.InventoryManager)- Exception thrown while activating [Resource[id=10397, uuid=353b527e-e9d3-4486-a04d-dbd5e2f735db, type={JBossAS7}Memory Pool Resource, key=core-service=platform-mbean,type=memory-pool,name=PS_Old_Gen, name=PS_Old_Gen, parent=memory-pool]].
org.rhq.core.clientapi.agent.PluginContainerException: Failed to start component for Resource[id=10397, uuid=353b527e-e9d3-4486-a04d-dbd5e2f735db, type={JBossAS7}Memory Pool Resource, key=core-service=platform-mbean,type=memory-pool,name=PS_Old_Gen, name=PS_Old_Gen, parent=memory-pool] - Failed to read attribute [usage-threshold-supported] of address [core-service=platform-mbean,type=memory-pool,name=PS_Old_Gen] - response: Result{outcome='failure', failureDescription=The server closed the connection before sending the response, rolled-back=false, rolledBack=false}
	at org.rhq.core.pc.inventory.InventoryManager.activateResource(InventoryManager.java:2070)
	at org.rhq.core.pc.inventory.InventoryManager.activateAndUpgradeResourceRecursively(InventoryManager.java:3590)
	at org.rhq.core.pc.inventory.InventoryManager.activateAndUpgradeResourceRecursively(InventoryManager.java:3592)
	at org.rhq.core.pc.inventory.InventoryManager.activateAndUpgradeResourceRecursively(InventoryManager.java:3592)
	at org.rhq.core.pc.inventory.InventoryManager.activateAndUpgradeResourceRecursively(InventoryManager.java:3592)
	at org.rhq.core.pc.inventory.InventoryManager.activateAndUpgradeResourceRecursively(InventoryManager.java:3592)
	at org.rhq.core.pc.inventory.InventoryManager.activateAndUpgradeResources(InventoryManager.java:3566)
	at org.rhq.core.pc.inventory.InventoryManager.initialize(InventoryManager.java:287)
	at org.rhq.core.pc.PluginContainer.initialize(PluginContainer.java:290)
	at org.rhq.enterprise.agent.AgentMain.startPluginContainer(AgentMain.java:1943)
	at org.rhq.enterprise.agent.AgentMain.start(AgentMain.java:697)
	at org.rhq.enterprise.agent.AgentMain.main(AgentMain.java:438)
Merged PR #1
As7 i-test: move ManagedServerTest up in the execution order, it seems
to be affected by earlier test classes.
as7 itests: Datasource Standalone resources cannot be tested with the simple ResourcesStandaloneServerTest workflow
Avoid java.lang.ClassCastException: java.lang.Boolean cannot be cast to java.lang.String in MemoryPoolComponent

Fix following commit "as7plugin: let MemoryPoolComponent start even if the underlying server is down"
[BZ 911432] - Alerts for events do not include 'source location' - adding the source location information to alert condition log. Column 'value' on table 'rhq_alert_condition_log' is limited by 255 characters so if the actual message is long enough the source location information can be lost.
[918207] Uninventorying resources for agents, on unreachable networks or waiting for registration, causes database hang
There are two underlying issues in this BZ. First, agent notifications
for uninventory are not protected via a short ping check. And second, our
current AgentClient.ping() returns true if a comm link can be established,
even if the agent is not accepting service requests.  Since by default we
don't timeout service requests, service requests can wait indefinitely for
an agent that is failing to connect.

This commit adds a new AgentClient.servicePing(long) which returns true
only if the agent can be reached, is accepting service requests, and returns
before the supplied timeout expires.  It also adds a call to this in the
uninventory SLSB, as well as converts existing ping() calls to pingService().
918207 - since we have the information, let's use it to proactively warn the user that an agent's clock is probably skewed
Merge pull request #6 from rhq-project/jshaughn/pingservice

[918207] Uninventorying resources for agents, on unreachable networks or...
Tabs hopefully removed now..
Fix MeasurementDataManagerTest#testFindCallTimeDataRaw
BZ 987628 - Agent can block indefinitely at startup

It appears the agent doesn't care that registration fails. The agent will
simply retry 5 times every 10 seconds, then the agent will block forever
waiting for the server to ping it, which won't happen.

This change basically forces a complete shutdown after registration fails and
displays an error as such.

There are a couple of cleanup things done for concurrency reasons as well.
BZ 987628 - Agent can block; Mars Rover behavior - retry forever

This patch makes the agent continue to try to connect, except in these cases:
1) The Agent object fails to construct.
2) The Agent is not the right version and cannot upgrade.
3) The Agent lost its token or has the wrong token
4) 'HelpException' - which happens through the command line interface
Throw exception if agentStatus returns value other than 0,1 or 3
BZ 987628 - if the agent isn't registered BUT it hasn't been able to even talk to a server yet, keep waiting.