Allow for better granularity when configuring JCR lock cleanup process

Background

Presently, the are multiple processes involved in the configurable garbage collection schedule. All of them share the same configuration, i.e. the same startup time and interval. It would be nice to have a better control over each process individually. In particular, for some consumers, it may be beneficial to be flexible in how frequently any expired JCR locks get cleaned up. If my understanding is correct, the existing lock cleanup process is not very expensive, since we do not need to scan the entire repository for the locked nodes, but instead, we have a centralized location where to search for those. Therefore, the lock cleanup can be scheduled to run on a more frequent basis than the rest of the cleanup processes involved in the garbage collection.

Proposal

Update existing configuration for garbage collection to support a configurable lock cleanup settings, e.g. something like the following:

"garbageCollection" : {
    "initialTime" : "05:00",
    "intervalInHours" : 5,
    "lockCleanup" : {
        "lockCleanupInitialDelayInMinutes" : 60,
        "lockCleanupIntervalInMinutes" : 180
    }
}

In order to remain passive, the new configuration option, i.e. lockCleanup, and any of its properties need to be optional. Here are the proposed defaults:

• lockCleanupInitialDelayInMinutes defaults to whatever is derived from initialTime at runtime
• lockCleanupIntervalInMinutes defaults to intervalInHours converted to minutes

With such an approach, we would not break any of the existing consumers, however, a fine-grained control over lock cleanup process would now be available to the consumers that need it.