Description
As mentioned by @wprzytula in #1029 driver tries to open control connection sequentially to the contact points - meaning that it moves to next contact point only after opening the connection to the previous one failed.
This may not always be the desired behavior.
The other possible improvement is to try opening connections to multiple contact points at the same time, as described in #1111
I think that instead of adding such options directly on SessionConfig, we could do it differently, more in line with how similar stuff is implemented in other parts of the driver:
- Introduce ControlConnectionPolicy trait. It would get info about contact points (and other peers after metadata is known), and decide to which of them we should try opening the connection.
- Similarly to LoadBalancingPolicy, we would implement a single default control connection policy. The builder of this policy would expose options described above - randomization and concurrency control.
Is there any reason to not do it this way? I don't think so, so I'll close the other 2 issues in favor of this one. If it turns out this approach is not the right one we can reopen them.