srm: Simplify scheduler configuration

The SRM scheduler has traditionally been quite cryptic to anybody not well
versed in the Scheduler internals - and not many people were. This patch
attempts to rectify this situation.

The patch introduces three configuration properties:

srm.request.max-requests   - max number of non-final requests
srm.request.max-inprogress - max number of requests being prepared
srm.request.max-transfers  - max number of turls

In addition, request specific versions of these properties are introduced.

The srm.request.{thread-queue-size,max-waiting-requests,ready-queue-size}
properties are obsolete.  The srm.request.max-ready-requests property is
deprecated. It's value is used for the new max-transfers setting.

The semantics of the max-by-same-user setting changes slightly in that it
now controls the transition from QUEUED to INPROGRESS and all requests
INPROGRESS and transferring count towards the limit.

There are no individual limits for the number of requests in TQUEUED or
RQUEUED. I think it is easier to understand a limit on the total number of
requests, and we shouldn't really care whether a request is in TQUEUED or
RQUEUED.

At least to me, these settings are far easier to understand: There is a limit
on the total number of requests before we begin to reject new requests; there
is a limit on how many requests we prepare concurrently (the
SRM_REQUEST_INPROGRESS status of SRM) and thus how much load we induce on other
services; and there is a limit on the number of concurrent client transfers
(number of turls).

The load reported to login broker has changed. It is now the total number of
requests in SRM_REQUEST_QUEUED or SRM_REQUESTS_INPROGRESS divided by the
max-inprogress setting. Thus when load is above 100%, new requests are queued.

The patch also applies some minor refactoring to the Scheduler and
ModifiableQueue classes.

Target: trunk
Require-notes: yes
Require-book: yes
Acked-by: Paul Millar <paul.millar@desy.de>
Patch: http://rb.dcache.org/r/6965/