Get rid of callback executor in CellNucleus

A bit of history: In the old days CellNucleus ran all callbacks in the thread
that added the message event to the queue - that's usually the sending thread.
This worked fine if the callbacks didn't do anything heavy; and it was
absolutely essential that they didn't do anything blocking.

Later this was extended with an option to instead spawn a new thread for each
callback invocation. This didn't have the downsides described above, but added
overhead by adding thread instantiation and a context switch.

Some years ago this was refactored with a callback executor in CellNucleus. The
default was single threaded, but multi-threaded callbacks could be injected.
This reduced the thread creation overhead, but now the context switch cost was
incurred for every callback. Since many callbacks simply set a flag or schedule
another task on another executor, this context switch is unnecessary.

Recently the synchronous message handling code was refactored to be build on
top of the asynchronous code. This introduced a deadlock potential, since a
thread issuing sendAndWait could be unable to receive the reply notification as
the callback would execute on a thread pool blocked by the sendAndWait call.

This removes the entire callback thread handling from CellNucleus. Instead it
uses a design inspired by Guava: Every callback registration also registers an
executor on which to run the callback. Thus the caller is responsible to choose
the callback policy, and can select whether to run the callback inline with the
message delivery thread, run it on a single thread executor or an a multi
thread executor. sendAndWait uses the MoreExecutors#sameThreadExecutor to
receive the signal independently from any executors, thus avoiding the
deadlock.

Other code is updated to provide an executor when registering the callback.
Often this is the sameThreadExecutor (similar to how it was in the old days)
since the callback doesn't do much more that set a flag, release a semaphor, or
maybe send another message with a new callback.

One problem is the SRM which has cheap callbacks, except for the getJob call:
That could potentially load the Job from the database, but since we lock all
jobs in memory, this will not happen in the current code. I plan to refactor
the SRM to execute the callbacks under the control of the Scheduler, but this
has not been done yet.

The patch obsoletes the following properties:

pool.cell.limits.callback.threads.min
pool.cell.limits.callback.threads.max
pool.cell.limits.callback.threads.max-idle-time
pool.cell.limits.callback.threads.max-idle-time.unit
pool.cell.limits.callback.queue.max

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