Upgrade BoneCP and Guava

BoneCP and Guava have to be upgraded together as the new BoneCP uses the new
Guava, and the new Guava is incompatible with the old BoneCP.

BoneCP 0.7 contains a bug in which it doesn't restore the auto-commit flag
on recycled connections. We work arround that problem in our code by carefully
resetting the flag before 'closing' the connection, however that only works
as long as you don't mix your code with eg DataNucleus. DataNucleus changes
the auto commit flag and thus you run into problems if your own code relies
on connections haven't auto commit enabled by default (as required by the
JDBC spec).

The problem is fixed in BoneCP 0.8, although that is only available in a release
candidate. rc3 has however been adopted by the Play project, which I consider
a high profile endorsement.

0.8-rc3 contains a bug in that the default auto-commit value is false rather
than true as required by the standard. I add a custom bonecp-config.xml to
work around that problem. The config also enables logging of slow statements
using a conservative 10 second threshold.

The BoneCP setReleaseHelperThreads method is deprecated in BoneCP 0.8 and I
removed all calls to it.

Guava removes the Ranges class, which means a number of classes had to be
updated to compensate.

Target: trunk
Require-notes: no
Require-book: no
srm: Fix authorization for srmv1 requests

Addresses an authorization regression in SRMv1 support.

When AuthorizationRecord was replaced by DcacheUser, SRMv1 authorization
broke. The SRMv1 code relies on SRMUser#equals to determine whether
the request query or update came from the same user that created the
request in the first place. Since DcacheUser doesn't implement equals,
this check always fails.

Rather than implement DcacheUser#equals, the SRM code is updated to
compare the IDs of the users instead. This SRM specific user identifier
is what is stored in the database, and in contrast to the DcacheUser
record, the ID can be restored from disk. The ID also ignores principals
like the Origin, which means that a request query or update will be
authorized even when issued from a different client host.

The patch only affects srmv1. Apparantly srmv2 doesn't do any
authorization checks.

Target: trunk
Request: 2.7
Require-notes: yes
Require-book: no
srm: Inject data source and transaction manager from Spring

The patch gets rid of the JdbcConnectionPool class. The BoneCP
dataSource and transaction manager are instantiated by Spring
and injected into the classes that operate on them.

Besides simplifying the code, the patch has the admin visible
consequence that only one connection pool is created in the
SRM. Previously there was one for the authentication store and
one for the remaining SRM tables. These are now served by a
single BoneCP connection pool (the wonders of using
standardized interfaces...).

New properties are:

srm.db.connections.partition-count=1
srm.db.connections.max-per-partition=50
srm.db.connections.min-per-partition=1

Target: trunk
Require-notes: yes
Require-book: yes
srm: Treat TReturnStatus as immutable

Replaces most TReturnStatus instantiations to treat the object as
immutable. Since TReturnStatus is auto-generated, it isn't possible
to actually make it immutable, but our code becomes cleaner if we
treat it as if it was.

I deliberately didn't change any of the status messages, except when
it was obviously wrong. Subsequent patches will focus on the status
messages.

Target: trunk
Require-notes: no
Require-book: no
srm: Clean up SRMServerV2

- Make fields private and final
- Use class name as name of the logger and make logger static and final
- Catch specific excptions
- Improve error messages, both as logged and returned to the client
- Use varargs when possible
- Treat srmPing differently than other requests

srmPing is special as it cannot return a failure. Therefore the failure
code had a special case to return a regular ping reply even in case of
failure (eg authentication failure). Rather than trying to force srmPing
into the regular handler processing, this patch adds an implementation
of srmPing directly in SRMServerV2 and completely bypasses the usual
request processing. Besides speeding up srmPing processing, this allows
us to remove the workaround in the failure path.

Target: trunk
Require-notes: no
Require-book: no
srm-server: Minor cleanup in Job class

Target: trunk
Require-book: no
Require-notes: no
Interim