spacemanager: Fix link group overallocation trigger

There is a database trigger that should prevent overallocation of link groups.
Over allocation can of course not be prevented as pools may go offline at any
time, but we can avoid that space manager increases its allocation beyond what
is available at a given moment in time.

The trigger fails a link group update if the available space is negative and
the amount of reserved space increases. This should allow reservations to be
decreased in size even when space is currently overallocated due to pools
being offline.

The existing check however fails for the use case of flushing files to tape:
The space consumed by flushed files is released back into the reservation. This
causes the reserved space in the link group to increase, but so does the free
space and the available space should thus be the same. The check however only
looks at whether the reserved space increases - not whether available space
decreases.

The fix is to look at the avaible space instead: Once negativ, no decrease in
available space is allowed. The challenge is that free space is updated
asynchronously - so the corresponding increase in free space may not be
reported until minutes later. The existing triggers already contained a
heuristic to decrease free space prior to the asynchronous update, but never to
increase it to avoid counting the same free space twice. The patch changes the
logic such that srmspace triggers both increase and decrease of free space in
the link group, however a before trigger on the link group ensures that only a
decrease is made persistent (thus still preventing counting free space twice).
The benefit is that the trigger can now get an accurate picture of changes in
available space. The change also makes the code more dry.

Target: trunk
Require-notes: no
Require-book: no
Acked-by: Paul Millar <paul.millar@desy.de>
Patch: http://rb.dcache.org/r/6515/