network utils: add constant for canonical host name

This patch is an add-on to 7127.  Since a number of alarm keys
need to include the host name in the set of identifiers,
the static initializer has been extended to make this
readily accessible as a static final field.

Target: master
Patch: https://rb.dcache.org/r/7140/
Require-notes: no
Require-book: no
Acked-by: Tigran
alarms: decorate data source to capture connector errors as alarms

This patch converts the alarm definitions which filter
database connection failures by creating a wrapper/decorator
class which logs these as Alarm types, and by substituting
the decorator class for its delegate classes in the
object field types and spring injection files.

It could be argued that a more elegant solution would
have been to do this using aspect (a natural fit), but
my experience with AspectJ is limited (coding examples
written during a workshop class), so I adopted this
approach as the shorter/quicker path.

Target: master
Patch: https://rb.dcache.org/r/7138/
Require-notes: yes
Require-book: no
Acked-by: Dmitry

RELEASE NOTES

Note: this patch ought to be applied together with 7137.
Since it falls under the general category of those
changes, no special notice need be given on the release notes.
src: move VspArgs into dcache-dcap module

Acked-by: Albert Rossi
Target: master
Require-book: no
Require-notes: no
poolmanager: remotve unused variable

Acked-by: Albert Rossi
Target: master
Require-book: no
Require-notes: no
alarms: convert definitions into marked alarms

Replaces the remaining server-side alarm definitions
currently shipped with an alarm marked at the point
of emission (the database-connection-related alarms
were taken care of by patch 7138).

Target: master
Patch: https://rb.dcache.org/r/7137/
Require-book: yes
Require-notes: yes
Acked-by: Tigran

BOOK:
RELEASE NOTES:

All predefined alarms which were previously shipped
as alarm definitions are now embedded in the code.
These are also given specific types, severity levels
and even unique keys, just as the xml definition
allows.

The procedure for generating a custom alarm definition
has remained unchanged, so sites can continue to augment the
number of errors to be marked as alarms via the alarms-
definition.xml file.

The web page filter box for string matches
no longer carries as a drop-down all predefined
alarms, since there are now many alarm types
that are "hidden" in the code itself. What is
displayed as a drop-down list are any and all
types currently in the data store (hence if
a known alarm type does not appear in that list,
it indicates that no alarm of that type has
been received or at least remains recorded in
the store).

The dcache alarm send command option '-l' now
refers to the Severity (CRITICAL, HIGH, MEDIUM
or LOW) and not to the logging level.

As a rule, one can expect that any alarms envisaged
by the developers will be of the embedded type,
and any alarms defined in the alarms-definition.xml
file will by subject to verification by the site
administrators (since they depend on logging
statements, care must be taken to make sure
they continue to match).

Because the alarms-definition.xml file is no
longer used to create the web page drop-down
list, a copy of it is no longer necessary on
the node running the httpd service. The
corresponding path property has been dropped
from the httpd.properties (defaults).
alarms: eliminate httpd.alarms.db.xml.path

Since it is not possible to stream an xml
file by giving the DataNucleus connector
a remote URL, the constraint that httpd
and alarms share a local (or mounted)
file partition for alarms data still
holds when the alarms.db.type is 'xml'.

The alarms.db.xml.path property is
a convenience so as not to have to define
the entire URL in case one wishes to
change the location of the store xml
file from the default.

The immutable httpd version of this
property was thus merely a mirror
defined for use in spring injection
(for internal use only).

However, it should be noted that,
subsequent to changes made in 02/2014
to the webadmin spring injection,
the data stores are now entirely
configured via spring profiles;
hence, the internal xml path field no
longer serves any purpose in
the dCache DataNucleusAlarmStore class.

This patch eliminates the (immutable)
httpd path property and also the
internal xml path field.

Testing:

Deployed, tested the various type
options on the httpd end (rdbms, xml, off).

Target: master
Patch: https://rb.dcache.org/r/7143/
Require-notes: no
Require-book: no
Acked-by: Tigran
alarms: eliminate httpd.alarms.db.xml.path -- missing deletion of batch check

This seems to have been caught while I was testing
but I neglected to update the patch accordingly.

It needs to be eliminated or httpd will not start now
(after commit 4a66f6c982a90024141e19b842d94ddfca005cdf).

Target: master
Patch: https://rb.dcache.org/r/7158/
Require-notes: no
Require-book: no
Acked-by: Gerd