Fix an ABA bug in the page cache

We were reusing the MuninnPage objects in the MuninnPageCache.freelist.
This could lead to cycles in the freelist through an ABA-bug.

The test that exposed that bug is ignored for now, because it is exposing
another bug that I thought was just a different manifestation of the ABA-bug.
Merge pull request #3247 from chrisvest/2.2-pagecache-freelist-aba

[2.2] Fix an ABA bug in the page cache
Fixes a test relying on recently changed index logging
Increase MaxPermSize to 512m for running Cypher acceptance tests
Throws NoSuchTransactionException in LogicalTransactionStore#getMetadataFor

instead of returning null. Will make for better error message in the log.
Reinstates the catching up with master before allowing transactions

this is to remove an unexpected pause that the first batch of transactions
would potentially run into as part of the store catching up in the
background. Having it explicit like this is more expected behaviour.
Merge pull request #3261 from tinwelint/2.2-reinstate-catchup

[2.2] Reinstates the catching up with master before allowing transactions
Merge pull request #3260 from tinwelint/2.2-throw-no-such-tx

[2.2] Throws NoSuchTransactionException in LogicalTransactionStore#getMetadataFor
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
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.
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
Fixed issue with input iterator starting too soon

CalculateDenseNodeStage was set up before executing NodeStage, accepting
an iterator of InputRelationship. Calculating the dense node count might
depend on IdMapper to be prepared. IdMapper was prepared after NodeStage
was done. Problem was that the Input used in this test wrapped the
iterator in a resource iterator that retrieved its first item in the
constructor and so made the first InputRelationship pick invalid node ids.

Effect of this would be that the node degree would be off by one for a
select few nodes.

Fixed by using PrefetchingResourceIterator instead which fetches in
hasNext, which is expected in most places.
Merge pull request #3268 from systay/cardinality-refactor

[2.2] Cardinality refactor