Extends gocql API for scylla shard aware info

[moguchev]

In our case, we encountered a problem when we need to insert and read more than 500 different keys (from different partitions) at a time in scyllaDB in one user request.

The insertion (BATCH request) still worked well, but reading queries (SELECT WHERE IN) left much to be desired.

We needed to extend the gocql API to be able to split keys/queries across hosts (or shards) on the side of our application and send queries to scyllaDB. This allowed us to reduce response time.

It might be useful to give this functionality. Well, or you can suggest a more elegant implementation than what I wrote :)

[sylwiaszunejko]

@moguchev Please squash your commits into set of independent changes. Correction commit affecting files changed in other PR commit should be squashed.

[moguchev]

@moguchev Please squash your commits into set of independent changes. Correction commit affecting files changed in other PR commit should be squashed.

done

[sylwiaszunejko]

@avelanarius Could you please review this PR to ensure everything is correct?

[moguchev]

I've changed go:build tags in unit tests and in integration tests.
Also I don't know why ./integration.sh tablet fails. My function should not affect on it.

[moguchev]

Also it's better to use ShardAwareRoutingInfo with enhancement from #165 because HostName will have a lot of calls in app.

[sylwiaszunejko]

@avelanarius Could you please review this PR to ensure everything is correct?

@avelanarius ping

[sylwiaszunejko]

@dkropachev Could you look at this PR?

[dkropachev]

@moguchev , thanks for contribution, I see you put lots of effort into it.

@sylwiaszunejko, I think we should not merge it as it is, functionally it is correct, except not covering tablets feature.
But there are major concerns:

1. It breaks single responsibility principle in regarding of what holds/generates routing information, currently it is tokenAwareHostPolicy but this PR makes Session do it as well.
2. Which leads to bad maintainability, for example if tablet feature logic have to be replicated in GetShardAwareRoutingInfo
3. This code is also does lot's of assumptions regarding configuration, for instance partitioner, HostSelectionPolicy and ConnPicker

Overall case is very valueable, not only for this particular driver.
Looking at the code, i beileve that we should extract and expose code that calculates routing information as it is done here, but on HostSelectionPolicy level and have an API for it on Session level, also to provide nice API to solve problem that is outlined in comments of GetShardAwareRoutingInfo, this API probably to be exposed on Session level as well

Update

Just FYI: rust-driver related issues: scylladb/scylla-rust-driver#468, scylladb/scylla-rust-driver#975, scylladb/scylla-rust-driver#944

[moguchev]

Thanks! I hope you'll add this in API

[dkropachev]

Thanks! I hope you'll add this in API

Thanks for you contribution, it give us very good clue, I have created an issue based on this PR, we would be happy to see your recommendations/comments there.