spacemanager: Fix DB trigger migration

The space manager liquibase files follow liquibase best practice
recommendations by placing stored procedures in a separate changeset.
Unfortunately, for triggers this is a bad advice: When making schema changes,
it is not uncommon to run update or delete queries that would cause the
triggers to execute. Thus trigger updates have to be carefully interleaved with
other schema changes.

This patch also resolves a typo in the 2.9 schema changes affecting the ability
to rollback the changes.

Let me stress that the liquibase best practice is still good advice: It should
however only be applied to stored procedures used by the application, not to
triggers.

Target: trunk
Require-notes: no
Require-book: no
Acked-by: Paul Millar <paul.millar@desy.de>
Patch: http://rb.dcache.org/r/6814/
srm: Avoid loading the same job multiple times

Restore from the database is suppossed to be fairly ordered: First the file
requests are read and added to an in-memory store and then the container
requests are read and an aggregation of the file requests is formed.

Unfortunately while reading the file requests, a debug log statement calls
Job#getSubmitterId which triggers an unexpected load of the container request.
This severily messes up restore from the database.

The patch removes this log statement. It also reduces some of the overhead of
loading the job history.

Target: trunk
Request: 2.8
Request: 2.7
Require-notes: yes
Require-book: no
Acked-by: Paul Millar <paul.millar@desy.de>
Patch: http://rb.dcache.org/r/6820/
Make RemotePoolMonitor asynchronous

RemotePoolMonitorFactoryBean creates a client stub for tansparently fetching
the pool monitor from pool manager. The existing code relies on a
ScheduledExecutorService to periodically fetch a copy of the pool monitor using
blocking sendAndWait calls.

This patch eliminates the executor, using a Guava CacheLoader instead. The
CacheLoader loads the pool monitor inline the first time it is accessed and
issues asynchronous updates after that. If not accessed for 10 minutes, the
cache is discarded and the next access is again blocking.

The code is different from the existing solution by:

- not requiring a ScheduledExecutorService

- by not fetching pool monitor unless it is actually used

- by discarding pool monitor after 10 minutes if unable to refresh it, thus
  avoiding that stale data is used

- by allowing fail fast behaviour rather than always blocking for
  pool monitor to be loaded

The last point is configurable: CellStub can be configured to retry on no route
to cell errors. The SRM is configured like that. In that case a call to pool
monitor may block until pool monitor was loaded from pool manager or until the
CellStub timeout has passed. Other errors are propagated right away.  This is
in contrast to the old code which would always block and could only be broken
by issuing a thread interrupt. Services other than the SRM use fail fast
behaviour when pool manager is down (for space manager and pin manager I think
we are better off bouncing the request to the door and let it decide what to
do; xrootd always prefers fail fast).

Target: trunk
Require-notes: no
Require-book: no
Acked-by: Paul Millar <paul.millar@desy.de>
Patch: http://rb.dcache.org/r/6825/
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/
spacemanager: Another hsqldb schema management fix

HSQLDB track trigger dependencies, so we have to drop triggers before
we can rename columns.

HSQLDB 2.3.2 also seems to have a bug in which it creates dependencies from
triggers that do not even refer to the column in question.  The patch
downgrades to 2.3.1.

Target: trunk
Require-notes: no
Require-book: no
Acked-by: Paul Millar <paul.millar@desy.de>
Patch: http://rb.dcache.org/r/6832/
chimera: do not explicitly update parent's mtime on create/remove

incrementing/decrementing link count does it as well.

Acked-by: Gerd Behrmann
Target: master
Require-book: no
Require-notes: no