Bug 535283 (RHQ-1996)

once upon a time measurement schedules used to require that an agent be online to receive those changes, otherwise the flow would fail.  this might not have seemed so bad for updating schedules against a single resource, but we also support updating schedules for compatible groups, auto groups, and across resource types (measurement templates).  so, this was corrected in RHQ-792, which allowed the agent to be down but still receive the updates.

the fix for RHQ-792 piggybacked on the logic that the agent uses for determining which resources it needs to merge, namely the mtime.  if the last modified time of the resource on the server is LATER in time than the one stored on the agent, then something about that resource changed and it will be synced...and one of the items in the synchronization payload are the measurement schedules for that resource.

as part of general performance fixes for the 1.2 release, it was determined that the mtime on the server was being reset too often.  this was because we were using a hibernate @OnUpdate persistence hook to update the mtime field to the current time each time the resource was merged through the entityManager.  however, the agent doesn't care about every single update made to a resource, related resource object, or misuse of entityManager.merge(Resource) calls.  instead, it only cares about whether the basic properties on a resource change, whether its corresponding measurement schedules have been updated, or whether it's plugin configuration has been updated.

to remedy this, the @OnUpdate hook was removed and "System.currentTimeMillis()" was placed into the setter methods for the properties of concern.  the mtime was also manually set in the code paths that update the measurement schedules (note: mtime resetting is not necessary at the time of this writing because plugin configuration updates are synchronous).

unfortunately, this solution was ignoring one very evident issue - the domain entities are shared between the agent and server.  so, although the side effect of resetting the mtime when certain setter methods were called on the resource in the server-side was correct, it posed problems when the mtime was reset on the agent side.  remember, we just mentioned that differing mtimes is the primary qualification that determines whether a resource needs to be synced / merged between agent and server.

consequently, the mtime was being reset too often, which ended up being the root cause of RHQ-1990.  although this was fixed with a one-off solution (namely resetting the mtime back down to 0 right at the end of the manual add workflow on the agent side) it's possible this mtime thing could come back to bite us later.  accordingly, the proper fix here is to remove the side-effect of updating the mtime in the setter methods of Resource entity, and instead do it explicitly in the server-side code paths that update the resource.