[#1063] Give back what the open reserved rather than what the configuration says by then, and ask for a restart when the cache size changes

[vharseko]

Summary

PDBStorage and JEStorage reserve their cache size from the server's MemoryQuota when they open and release it
when they close - both times by reading the configuration they hold at that moment. A change of db-cache-size or
db-cache-percent on a running backend swaps that configuration (applyConfigurationChange ends in config = cfg)
without touching the quota or the cache, and neither property is marked as needing a restart. So the storage reserves
the old size and releases the new one at the next close - the disable an online import-ldif makes included - and
the quota drifts by the difference for the life of the JVM: a cache grown from 64 MB to 128 MB leaves the quota
believing 64 MB free that the server does not have; a shrink leaves 64 MB reserved by nobody. The running cache is
the old size throughout, and dsconfig reports the change applied.

Fixes #1063.

What changes

Both storages keep two numbers of their own instead of reading config twice:

• configuredCacheSize - the cache size of the configuration the storage opened with (for PDB, what the buffer pool
  was built to);
• reservedCacheSize - of it, what the quota granted. acquireMemory is a tryAcquire: refused, it reserves
  nothing, and the return value used to be ignored in both buildConfigurations, so a close released a size that
  was never taken. That is reachable without any change - the server does not call isConfigurationAcceptable for
  the backends it opens at startup.

close() gives back reservedCacheSize. isConfigurationChangeAcceptable admits the difference to what is held
rather than to config: once a change has been admitted but not applied, computeSize(config) is already the new
size while the reservation is the old one, and a second change was admitted for a difference nobody would reserve.
applyConfigurationChange on an open storage whose cache size the change moves sets adminActionRequired and adds
NOTE_CONFIG_DB_CACHE_REQUIRES_RESTART (630), naming the size the backend runs with and the one now configured.

db-cache-size and db-cache-percent are marked component-restart in PDBBackendConfiguration.xml and
JEBackendConfiguration.xml, as db-directory is in the same files, so dsconfig says so too.

Why a restart rather than a resize

PersistIt sizes its buffer pool when the database opens and has no way to resize it (Persistit.setConfiguration
refuses a second configuration). JE could - je.maxMemory and je.maxMemoryPercent are mutable through
Environment.setMutableConfig - but JEStorage has never resized its environment, and it is not alone: none of the
JE properties the pluggable backend left without requires-admin-action is applied live since OPENDJ-1719 dropped
the setMutableConfig road of the old backend. Restoring that road for all of them is #1068; here the two
storages take the same shape, and the quota follows the cache that actually runs.

Stacked on #999

The fix builds on the close() of #999 (the quota given back once, ahead of the database) and on JEStorageTest,
which #999 introduces; the branch sits on its head (fd50d19dcb). Merge after #999.

Tests

PDBStorageTest and JEStorageTest, six cases each, over a mocked ServerContext with a fresh MemoryQuota:

• aCacheGrownWhileOpenIsGivenBackAsItWasTaken, aCacheShrunkWhileOpenIsGivenBackAsItWasTaken - the quota is
  back where it started after open, change, close;
• aCacheSizeChangedWhileOpenAsksForARestart - adminActionRequired, the message id and both sizes;
• aChangeWhichLeavesTheCacheSizeAloneAsksForNothing - a change of another property asks for nothing, as before;
• aCacheSizeChangeIsAdmittedAgainstWhatTheStorageHolds - with 64 MB held and a change to 128 MB pending, 256 MB is
  refused and 192 MB admitted at 129 MB free;
• aReservationTheQuotaRefusedIsNotGivenBackOnClose - 32 MB free, a 64 MB cache opens, and the close leaves 32 MB.

Five of the six were red on the head of #999 before the fix (the sixth pins existing behaviour): +64 MB, −64 MB,
admission of 256 MB, no admin action, 96 MB after the close of a refused reservation.

Mutants, each run against both classes: close() releasing configuredCacheSize instead of the reserved size
(the refused-reservation case red, nothing else), admission against computeSize(config) (the admission case),
setAdminActionRequired dropped (the restart case), and the old release by config (grow, shrink and the refused
reservation).

Regression set (one JVM per class, the fixed storages first on the classpath): FailedBackendOpenTest,
PDBTestCase, EncryptedPDBTestCase, JETestCase, EncryptedJETestCase, ReplayedConfigChangeTest,
OnDiskMergeImporterTest, PersistentCompressedSchemaTest, DN2IDTest, StateTest, ID2EntryTest,
ID2ChildrenCountTest, BulkCursorTest, DefaultIndexTest, ImportLDIFTestCase, RebuildIndexTestCase,
VerifyIndexTestCase, BackendConfigManagerTestCase - 240 tests, 0 failures (FailedBackendOpenTest and
PDBTestCase re-run after a collision on the admin port 65534 with another JVM on the machine).

Not in this PR

• A JE backend with an explicit db-cache-size takes that size from the server's memory quota twice per open and gives it back once #1067 - ConfigurableEnvironment.validateDbCacheSize takes db-cache-size from the server's quota as a
  probe and never gives it back, so every open of a JE backend with an explicit size leaks one cache size. A
  reservation outside the pair this PR closes; the mock quota the tests here assert on does not see it.
• JE and PDB backend properties without requires-admin-action are neither applied to a running backend nor reported as needing a restart #1068 - the other JE properties (and PDB's db-checkpointer-wakeup-interval) that are neither applied live
  nor marked as needing a restart.