Single thread pulling updates on HA machines

Moving from an HA communication design where updates gets streamed from
the master on most individual requests coming from slaves. This design
caused lots of duplicate transactions being streamed from master to each
slave, specifically if slaves issued write requests to the master.

Moving to a design where slave communication with its master does not
stream back transactions, except when doing store copy. Instead master
returns a transaction obligation saying which transaction id that must be
applied in order to continue. The slave will notify the single update
puller about that and will in turn be notified by the update puller
when that transaction has been applied. Many requests can poke the update
puller simultaneously and transaction pulling will piggy back on each
other, since there's only one thread pulling.

Benefits include:
- No code explicitly dealing with and preventing pull storms
- Less network communication with master
- Less load put on master
- Possibility for more optimizations regarding applying updates on slaves
  since updates are pulled in a single thread only.
Removed unnecessary TxIdGenerator abstraction
Slaves applies transactions from master in batches

by having a specific TransactionAppender that doesn't do auto-forcing.
And since there's only one thread on each slave receiving transactions
from its master they are queued and applied in one go now and then like:

- append all queued transactions to log
- force log
- apply all queued transactions to store
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.
Splits UpdatePuller into two roles: obligation fulfiller and update puller
Added tests for unexpected/invalid input data
Merge pull request #3236 from tinwelint/2.2-single-update-puller

[2.2] single update puller in HA
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
Reflective bing
Adding scala-reflect
Reflective perty
Make drills be extractors (and comment out a lot of things to keep it
all compiling)
Update LICENSE files for scala reflect
Add DocOp and evalDocOps
Remove bling and refactor Extractors to be more practical
Rebuild pprintToString
Fix perty docGens
Fix Pretty DSL so that we can work with different types without calling pretty