pool: Fix interpretation of eager option of migration module

Migration module will try to reuse existing replicas on target pools. This is
how idempotence is achieved. When a pool with an existing replica fails to
process a request from migration module, the request will patiently be retried.
This can be surpressed using the -eager option. If used, this causes the
migration module to proceed to creating a new replica.

There is a flaw in the interpretation of not specifying -eager: If a pool is
down and not registered in pool manager, the pool information provided by pool
manager does not include those pools. Thus even though existing copies existing
on target pools, those pools are invisible to migration module. Thus despite
not being eager, a migration job would proceed with creating new replicas.

This patch fixes the problem by including offline pools in the query reply from
pool manager. The information is added in such a way that old pools without
this patch will not be affected by the change. If a pool is updated without
updating pool manager, the message will return an empty list for offline pools,
effectively maintaining the old semantics. This to fix the problem, both pool
manager and pools have to be updated, but the change is fully backwards
compatible.

The semantics of the -include-when and -exclude-when options is tricky as they
break idempotence. For offline pools, these expressions cannot be interpreted
and thus a migration job may block on an offline pool that would have been
excluded by these expressions had the pool been online. The proper fix is to
replace the -include-when and -exclude-when options with something that is
idempotent, but such a change would not be applicable to stable branches. The
present patch is kept minimal so it can be included on stable branches.

Target: trunk
Request: 2.10
Require-notes: yes
Require-book: yes
Acked-by: Albert Rossi <arossi@fnal.gov>
Patch: https://rb.dcache.org/r/7345