Fix executor flaws

One has to be careful when using ThreadPoolExecutor, as it works differently
from what one may expect: When configured with a range of threads [core;max]
and a bounded or unbounded queue, it prefers to queue before creating more
threads.  With an unboudned queue this means it will never create more than the
core threads.  With a bounded queue, it will not create more than core threads
until the queue is full.

This is different from what one may have inteded: To create a mininum number of
threads, increase up to a maximum number and then start queuing. E.g. our old
in-house thread pools worked like that.

The logic behind ThreadPoolExecutor does make sense for some scenarios: The
idea is to have the core threads for steady state operation, with a queueing to
handle fluctuations in the in-flow. Once the queue is full this is considered a
beginning overload and the number of threads is increased as a response. This
strategy minimizes the thread churn, and it works well if tasks are always CPU
bound (ie for non-blocking tasks). For blocking or mixed tasks, the strategy is
unfortunate as it will cause slow response time due to the queue having to fill
up before creating more threads.

This patch fixes three services where I clearly forgot about the semantics of
ThreadPoolExecutor:

Pool manager's request container uses non-blocking tasks, so the model of
ThreadPoolExecutor works well - I use the number of processors as the core
size, with a small queue limit and allow scaling to the configured maximum
number of threads (the existing code would never use more than one thread;
the code in 2.7 would never queue; the code before ThreadPoolNG would use
an unlimited queue and scale threads from one and up to the limit).

For SRM I adjust the defaults to not allow queueing, and instead create more
threads up to an increased limit. SRM hardly gets any inbound messages
(except replies, but they are not submitted to this thread pool), so this
strategy should work.

For space manager I introduce a BoundedExecutor which has semantics closer
to what one may expect. Allow creation of up a limited number of threads
with queueing once the limit has been reached. I think this model works
better for executors that receive mixed blocking and unblocking tasks.
We may extend BoundedExecutor with the ability to place a bound on the
queue length, but this has not been implemented yet.

Target: trunk
Require-notes: yes
Require-book: no
Acked-by: Tigran Mkrtchyan <tigran.mkrtchyan@desy.de>
Patch: http://rb.dcache.org/r/6828/