pool: Fix persistence of sticky bits

Motivation:

Patch dbb1294 contains a regression that
causes pools with the Berkeley DB backend not to persist changes to the sticky
flags to disk. The problem only affects changes that are applied after the
replica is created as upon regular write to a pool the sticky bits are set
before the entry is updated to the final state and the final state update
triggers a write to disk.

Specific cases in which one would be affected:

- Manually using rep set sticky

- Using migration move or an equivalent command when the target replica
  already exists and only the state needs to be replicated

In these cases in may be that pools are lacking a sticky bit. The problem
will only be apparent after a pool restart.

Modification:

Save the state after modifying the sticky bits.

Result:

The bug is fixed, but we still need a procedure for detecting damage done
and repair as much as possible.

Target: trunk
Require-notes: yes
Require-book: no
Request: 2.14
Request: 2.13
Request: 2.12
Acked-by: Albert Rossi <arossi@fnal.gov>
Acked-by: Paul Millar <paul.millar@desy.de>

modules/dcache/src/main/java/org/dcache/pool/repository/meta/db/CacheRepositoryEntryImpl.java

@@ -283,6 +283,7 @@ public synchronized boolean setSticky(String owner, long expire, boolean overwri
         builder.addAll(filter(_sticky, r -> !r.owner().equals(owner)));
         builder.add(new StickyRecord(owner, expire));
         setStickyRecords(builder.build());
+        storeState();
         return true;
     }