CassandraSinkCluster: Control connection always connects to configured dc/rack

[rukai]

closes #758

The new logic looks like:

1. when we receive our first message populate local_nodes immediately if possible (if not now then we have to wait till handshake is complete)
2. process handshake
3. when we receive confirmation that handshake is complete:
   1. send handshake to topology task
   2. if local_nodes is empty then
      1. populate local_nodes blocking until topology task has completed once. (on my machine in int tests this takes ~50ms)
      2. replace control connection with a new connection guaranteed to be from the dc/rack
4. system.local queries are always routed to a dc/rack node giving us more correctness and allowing us to remove some unneeded logic.

This didnt end up cleaning up as much code as I had originally hoped, the system.peers rewriting still needs to perform its own system.local and system.peers queries regardless, but I think it is still the most correct approach.
I think that the consistency of always having our control connection connect to our dc/rack should help avoid some nasty and hard to detect edge cases.