CappedOperation does not trigger on first time event

Previously, a CappedOperation was triggered the first event regardless of
which triggered were specified. This was unexpected and counter intuitive,
especially for cases (where it is most used) where a CappedOperation was
added as a time-based logger and a log statement was expected to be
printed after the specified threshold, it would log immediately as well.
Removes console output from GraphDatabaseServiceTest
Fixes XaLogicalLog shutdown issue

XaLogicalLog.close() was flushing the store files after
 marking the active log file as applied. This could
 lead to recovery not happening if shutdown
 failed within a narrow window between log
 shutdown and store flush. This is now fixed.
The LogBackedXaDatasource defined a stop() method that
 managed log lifecycle without having to. This is now
 removed and log lifecycle control is delegated to
 subclasses through XaContainer.
Merge pull request #3229 from digitalstain/1.9-fix-llog-shutdown

[1.9] fix logical log shutdown
Merge pull request #3227 from tinwelint/1.9-capped-ops-no-first

[1.9] CappedOperation does not trigger on first time event
Fixes BackupServiceIT to properly close log channel after latest changes
Batch importer input from csv files

Initially from Michael Hunger, @jexp

Focuses on seeking in the raw character array stream from the provided
Readable and tries to avoid creating Strings as far as possible. Value
extraction revolves around visiting the character array with an offset and
length and extract the type of value requested.

Joined the Iterable<InputNode> and Iterable<InputRelationship> into an
Input argument to the BatchImporter and added a CsvInput implementation
with factory for header information, possible to read from the provided
node/relationship data files or from any source.

Also added a side-kick thread, wrapping any Readable reading a chunk ahead
in a separate thread so that the actual thread reading input will not have
to wait for I/O.
Deleted nodes includes deleted dynamic label records

If a node that got deleted had dynamic label records they weren't
included in the "after" state of a node record, which means they wouldn't
be deleted when applying that node command on the store. Later on such
dynamic records would be viewed as inconsistencies since their owner was
not in use anymore.

This issue was recently introduced where some amount of cleverness was
removed from the store applier, cleverness including looking at
before/after start and merging the two, infering which records should be
deleted.

Now when writing a node record its dynamic records are always written to
the log, and always read back when reading from the log. Also when
deleting a node simply mark all dynamic label records as not in use
instead of clearing the list on the node record itself. This go hand in
hand with what is done around dynamic records in property records.
Added tests for unexpected/invalid input data
Merge pull request #3201 from tinwelint/2.2-del-dyn-label-records-w-del-node

[2.2] Deleted nodes includes deleted dynamic label records
Merge pull request #3196 from tinwelint/2.2-batch-import-csv-input

[2.2] Batch importer input from csv files
Merge remote-tracking branch 'origin/1.9-maint' into 2.0-maint

Conflicts:
	community/kernel/src/main/java/org/neo4j/kernel/impl/nioneo/xa/NeoStoreXaDataSource.java
	community/kernel/src/test/java/org/neo4j/graphdb/GraphDatabaseServiceTest.java
	community/kernel/src/test/java/org/neo4j/kernel/impl/nioneo/store/TestXa.java
	community/kernel/src/test/java/org/neo4j/kernel/impl/transaction/xaframework/XaLogicalLogTest.java
	community/kernel/src/test/java/org/neo4j/kernel/impl/util/CappedOperationTest.java
	community/lucene-index/src/main/java/org/neo4j/index/impl/lucene/LuceneDataSource.java
	enterprise/backup/src/test/java/org/neo4j/backup/BackupServiceIT.java
Merge remote-tracking branch 'origin/2.0-maint' into 2.1-maint

Conflicts:
	community/kernel/src/main/java/org/neo4j/kernel/impl/nioneo/xa/NeoStoreXaDataSource.java
	community/kernel/src/main/java/org/neo4j/kernel/impl/transaction/xaframework/XaLogicalLog.java
	community/kernel/src/test/java/org/neo4j/kernel/impl/nioneo/store/TestXa.java
	community/kernel/src/test/java/org/neo4j/kernel/impl/transaction/xaframework/XaLogicalLogTest.java
	community/lucene-index/src/main/java/org/neo4j/index/impl/lucene/LuceneDataSource.java
	enterprise/backup/src/test/java/org/neo4j/backup/BackupServiceIT.java
Merge remote-tracking branch 'origin/2.1-maint'

Conflicts:
	community/kernel/src/main/java/org/neo4j/kernel/impl/nioneo/store/StoreFileChannel.java
	community/kernel/src/main/java/org/neo4j/kernel/impl/nioneo/xa/NeoStoreXaDataSource.java
	community/kernel/src/main/java/org/neo4j/kernel/impl/transaction/xaframework/LogBackedXaDataSource.java
	community/kernel/src/main/java/org/neo4j/kernel/impl/transaction/xaframework/XaContainer.java
	community/kernel/src/main/java/org/neo4j/kernel/impl/transaction/xaframework/XaLogicalLog.java
	community/kernel/src/test/java/org/neo4j/kernel/impl/nioneo/store/TestXa.java
	community/kernel/src/test/java/org/neo4j/kernel/impl/transaction/DummyXaDataSource.java
	community/kernel/src/test/java/org/neo4j/kernel/impl/transaction/TestXaFramework.java
	community/kernel/src/test/java/org/neo4j/kernel/impl/transaction/xaframework/XaLogicalLogTest.java
Re-enable the CommitPusher. More thought need to go into whether it's good or bad
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
Change cardinality estimation to assume independence between predicates