Add retry policy and fix documentation for Cassandra storage backend

[byumov]

Shortly, this PR fixes two problems:

1. Current documentation for Cassandra backend is incorrect
2. There is no option to change the default retry policy for cluster now

More details below...

1. Current documentation says, that default value for connection_timeout is 0, you might think there is no timeout by default, but in fact, if we don't set these options timeout will be 600ms.
   see:

   vault/physical/cassandra/cassandra.go

   Lines 127 to 133 in 0e8c6c2

   	if connTimeoutStr, ok := conf["connection_timeout"]; ok {
   	connectionTimeout, err := strconv.Atoi(connTimeoutStr)
   	if err != nil {
   	return nil, fmt.Errorf("'connection_timeout' must be an integer")
   	}
   	cluster.Timeout = time.Duration(connectionTimeout) * time.Second
   	}

   
   cluster.Timeout is not changing somewhere else and get default value:
   

   vault/vendor/github.com/gocql/gocql/cluster.go

   Line 49 in 665d668

   Timeout time.Duration // connection timeout (default: 600ms)

2. If we have a Cassandra cluster with several nodes, we don't want to get an error if one of nodes has gone. For supporting this behavior with gocql(which used in Cassandra backend) we must set one of RetryPolicy for the cluster: https://github.com/gocql/gocql/blob/5913df4d474e0b2492a129d17bbb3c04537a15cd/policies.go#L158
   By default(current behavior) cluster use "retry on same connection" policy. So, if current active node is down client will get an error:
   https://github.com/gocql/gocql/blob/5913df4d474e0b2492a129d17bbb3c04537a15cd/policies.go#L141
   We can easily fix this by using SimpleRetryPolicy (retry for another connection) when creating the cluster.

Also, one new option added to set timeout for the initial connection.

I tried to make changes as little as possible.
This PR doesn't change the behavior of current installations.

[byumov]

@ncabatoff, Hi! Could you take a look, please?

[aphorise]

Enhancement request along with accompanying documentation improvements do seem relevant. Can this be reviewed for release in the near future?

[aphorise]

Likely related to #15899 - and on merger user on that issue should be advised to retest before closing that issue too.

[HridoyRoy]

lgtm

[HridoyRoy]

The changelog check is ok -- I triggered the CI run off another branch and PR, so the check is looking for the wrong changelog entry.

[Zlaticanin]

LGTM. We gave it a test run and it all seems good! 👍