Deprecate access latency, retention policy and file size in StorageInfo

Some information can be represented in both StorageInfo and
FileAttributes. This duplication is unfortunate as it makes
the code much harder to read and is counter to the fine grained
granularity that was intended with the FileAttributes class.

This patch deprecates the access latency, retention policy and
file size fields in Storage Info. I cannot completely remove them
as:

- We need to maintain protocol compatibility with older pools

- The HSM scripts rely on those attributes as part of the
  storage info argument (which contains the toString() version
  of the StorageInfo).

- Pools have persistent copies of StorageInfo as part of their
  meta data.

I renamed the accessors to make it obvious that one should avoid
using them. They are now only used in some conversion code between
StorageInfo and FileAttributes, some unit tests, and a utility
to deserialize a StorageInfo from a file. For most of dCache,
these fields will not have been initialized.

Chimera is updated to decouple access latency and retention policy
from storage info.

The pool is updated to push FileAttributes all the way into the meta
data stores, although the stores will convert it to StorageInfo for
persistence. We need this to maintain backwards compatibility with
existing pools. The process is lossy, but all information we need is
maintained. I extended the flag-c map entry in StorageInfo to take
a comma-separated list of checksums.

Note that we documented some of the deprecated StorageInfo fields
as part of the billing file format strings. We did not use these
fields in our default patterns, but the change should be documented
in the release notes (ie removal of storageInfo.fileSize,
storageInfo.retentionPolicy, storageInfo.accessLatency). A later
patch will update the info messages to use file attributes, thus
reexposing the lost fields.

Dead code affected by the change is deleted.

Target: trunk
Require-book: no
Require-notes: yes
Acked-by: Paul Millar <paul.millar@desy.de>
Patch: http://rb.dcache.org/r/5324/
pool: Rewrite checksum module

- Introduces an interface for checksum module.

- Removes name space chatter from checksum module (thus
  allowing checksum reads and checksum updates to be
  combined with other operations). This eliminates some round
  trips between pool and name space.

- ReplicaDescriptor is extended with methods to fetch and
  store checksums. Most ChecksumModule methods operate on
  a ReplicaDescriptor rather than a file.

- Changes the unused FILESIZE_MISMATCH CacheException to
  FILE_CORRUPTED and introduces the FileCorruptedCacheException
  class. It is used to signal both checksum and file size
  mismatch errors.

- The new code works with collections of checksums in most places (the
  mover interface has not been updated for this yet).

- The new code looks at known checksums to decide which checksum
  to compute (rather than always defaulting to ADLER32 and hoping
  that's the checksum we had before).

  This last point is user visible, as we now may compute and verify
  different checksum types from before.

Target: trunk
Require-book: no
Require-notes: yes
Acked-by: Paul Millar <paul.millar@desy.de>
Patch: http://rb.dcache.org/r/5327/
pool: Use DiskErrorCacheException rather than CacheException.ERROR_IO_DISK

Target: trunk
Require-book: no
Require-notes: no
Acked-by: Paul Millar <paul.millar@desy.de>
Patch: http://rb.dcache.org/r/5335/
srm: Log stack trace for bugs while saving jobs

I ran into a IllegalStateException during SRM startup and no
stack trace was logged. This patch adds the code to log a stack
trace when this error occurs. The error itself is not resolved.

Target: trunk
Require-notes: no
Require-book: no
Acked-by: Paul Millar <paul.millar@desy.de>
Patch: http://rb.dcache.org/r/5382/
srm: Fix IllegalStateException during startup

When an expired job exists while the SRM is starting, the following exception
is generated:

03 apr 2013 11:07:53 (SRM-Gerds-MacBook-Pro) [] Failed to save SQL request to database. Please report to support@dcache.org.
java.lang.IllegalStateException: not initialized
        at org.dcache.srm.scheduler.JobStorageFactory.getJobStorageFactory(JobStorageFactory.java:36) ~[srm-2.6.0-SNAPSHOT.jar:2.6.0-SNAPSHOT]
        at org.dcache.srm.request.Job.getJobStorage(Job.java:281) [srm-2.6.0-SNAPSHOT.jar:2.6.0-SNAPSHOT]
        at org.dcache.srm.request.Job.saveJob(Job.java:299) [srm-2.6.0-SNAPSHOT.jar:2.6.0-SNAPSHOT]
        at org.dcache.srm.request.Job.saveJob(Job.java:286) [srm-2.6.0-SNAPSHOT.jar:2.6.0-SNAPSHOT]
        at org.dcache.srm.request.Job.setState(Job.java:599) [srm-2.6.0-SNAPSHOT.jar:2.6.0-SNAPSHOT]
        at org.dcache.srm.request.Job.setState(Job.java:440) [srm-2.6.0-SNAPSHOT.jar:2.6.0-SNAPSHOT]
        at org.dcache.srm.request.Job.expireJob(Job.java:1015) [srm-2.6.0-SNAPSHOT.jar:2.6.0-SNAPSHOT]
        at org.dcache.srm.request.Job$LifetimeExpiration.run(Job.java:993) [srm-2.6.0-SNAPSHOT.jar:2.6.0-SNAPSHOT]
        at java.util.TimerThread.mainLoop(Timer.java:555) [na:1.7.0_11]
        at java.util.TimerThread.run(Timer.java:505) [na:1.7.0_11]

This is caused by the expiration task needing access to the JobStorage
before the JobStorageFactory is initialized.

The patch restructures initialization to resolve this problem.

Target: trunk
Request: 2.5
Request: 2.2
Request: 1.9.12
Require-book: no
Require-notes: yes
Acked-by: Paul Millar <paul.millar@desy.de>
Patch: http://rb.dcache.org/r/5385/
pom: scm should point to github

Acked-by: paul Millar
Patch: http://rb.dcache.org/r/5395/
Target: trunk, 2.5, 2.2, 1.9.12
Require-book: no
Require-notes: no
Merge branch 'devel'