Bolt+routing

[ekampp]

Based on this, previous dicussion, this attempts to reimplement bolt+routing for causal cluster load balancing.

[coveralls]

Coverage decreased (-3.8%) to 86.814% when pulling e1be7fa on systems-engineering:master into 4b649fc on neo4jrb:master.

[coveralls]

Coverage decreased (-3.8%) to 86.814% when pulling e1be7fa on systems-engineering:master into 4b649fc on neo4jrb:master.

[coveralls]

Coverage decreased (-3.8%) to 86.814% when pulling e1be7fa on systems-engineering:master into 4b649fc on neo4jrb:master.

[coveralls]

Coverage decreased (-3.8%) to 86.814% when pulling e1be7fa on systems-engineering:master into 4b649fc on neo4jrb:master.

[coveralls]

Coverage decreased (-3.8%) to 86.814% when pulling e1be7fa on systems-engineering:master into 4b649fc on neo4jrb:master.

[coveralls]

Coverage decreased (-3.8%) to 86.814% when pulling e1be7fa on systems-engineering:master into 4b649fc on neo4jrb:master.

[klobuczek]

@ekampp this PR implements only the load balancing aspect of causal clustering. Full clustering cannot be implemented with an adapter and without changes to the current neo4jrb DSL and the client code. What is missing is handling bookmarks to ensure reading your own writes. With the current adapter approach, 1 transaction per query, this is not achievable. We intend to provide explicit session and transaction demarcation in neo4j-10.0.x the same way as in neo4j-ruby-driver. The bookmarks obtained from a session must be provided to the next session if a guarantee is needed that all transactions are routed to servers caught up with all transactions of the previous session.

[ekampp]

@klobuczek, thanks for the feedback!

I have also added this PR to neo4j it self for the session management.

When is 10.0.x expected to be launched, and how will that help this situation? I'm not sure I understand the jargon around transaction demarcation. Sorry.

Thanks,
Emil