Guards for concurrent shutdown when applying batches on slaves

Committing and applying a batch of transactions in
TransactionCommittingResponseUnpacker would:
- 1. append a batch of transactions
- 2. force
- 3. then finally mark as committed and apply each one

If there would occur a clean shutdown during or after 1 or 2, but before 3
there might be transactions appended to the log, but never applied, not
even the next start of the db, since there would be no recovery performed.
A similar problem could occur for rotation where force (2) would check
rotation which would effectively exhibit very similar problems.

This commit adds synchronized using the same monitor as append and shutdown
for one whole transaction batch to guard for concurrent shutdown. Also
TransactionAppender#force (2) is changed to not check rotation, and
instead the TransactionCommittingResponseUnpacker checking rotation before
committing and applying each batch, i.e. no possibility of rotation
happening in between append and commit-and-apply.
Merge pull request #3265 from tinwelint/2.2-slave-batch-commit-fix

[2.2] Guards for concurrent shutdown when applying batches on slaves
Revert the change which adds count values in the state on read

- it is indeed better to delegate the caching to the page cache used in the CountStore
- having less values in the in-memory state will also make the sorting much faster when we need to merge them
  with the one on disk
Increase key-value record size to 16 + 16 bytes

- change node and relationship key encoding to write a type byte
- extract CountsStoreWriter and added tests
- fix a bug in the binary search when reading entries ordered by key
Stop visiting records when reading an empty one from the page
Add tests for CountsStore
Extract record serialization outside the CountsStore

Now the CountsStore accept generic keys
Change CountsStore.get to accept a register rather than returining a long
Make the counts store generic on values type
CountsStore takes a WriterFactory rather than creating a specific CountsStoreWriter
Repackaging to separate the concepts of KVStore and CountsStore

- revisit KeyValueRecordVisitor to be generic
- the specific CountsStore visitors uses registers rather than passing aroung longs
Rollback to assuming dependence between predicates
Change the abstraction used for switching cardinality models

 * Instead of using SelectivityCombiner as the abstraction that
   is used to switch between different models,
   QueryGraphCardinalityModel is now the abstraction to use
Added assumeIndependence cardinality model
Added exponential backoff as a selectivity combination strategy
Changes communication between appender and forcer in batched writes

to only rely on appender ticket and force ticket, w/o even involving last
committed transaction id, which was an unncessary involvement.
Also added tests to absolutely make sure that appender waits for correct
round of force, even in the face of ticket long values wrapping around
Long.MAX_VALUE.
Tagging for version 1.9.9
Change cardinality estimation to assume independence between predicates
Fixed the serialization of PlanDescription.

Prior to this fix, DbHits, Rows, EstimatedRows and IntroducedIdentifier were not serialized
correctly, e.g. DbHits(5) was serialized as "DbHits(5)" instead of just "5". The child plan descriptions
were also incorrectly handled and has been adressed by this fix.
Merge pull request #3264 from tinwelint/2.2-correct-batch-force

[2.2] Changes communication between appender and forcer in batched writes