Cassandra: disable read_repair_chance & read_repair_chance

https://issues.apache.org/jira/browse/CASSANDRA-13910

1. most inconsistencies are actually fixed by hints in practice; and in the case where a node stay dead for a long time so that hints ends up timing-out, you really should repair the node when it comes back (if not simply re-bootstrapping it). Read-repair probably don't fix that much stuff in the first place.
2. again, read-repair do happen without those options kicking in. If you do reads at QUORUM, inconsistencies will eventually get read-repaired all the same. Just a tiny bit less quickly.
3. I suspect almost everyone use a low "chance" for those options at best (because the extra resources consumption is real), so at the end of the day, it's up to chance how much faster this fixes inconsistencies.

Looking at some production table settings (example):

CREATE TABLE ....blobsinbucket (
    bucket text,
    id text,
    position int,
    PRIMARY KEY ((bucket, id), position)
) WITH CLUSTERING ORDER BY (position ASC)
...
    AND dclocal_read_repair_chance = 0.1
...
    AND read_repair_chance = 0.0
    AND speculative_retry = '99PERCENTILE';

We can see that we still have dclocal_read_repair_chance.

We should likely disable dclocal_read_repair_chance by default at table creation time...