Fix table configuration issues

[timmaxw]

In raft we currently don't show issues in the web UI if there are problems with table configuration. This needs to be fixed.

This is a bit tricky because we can no longer check the table config on each server separately; instead, the servers hosting the data have to check the table config and then forward the issues over the network to the server reporting the issues. We already have a mechanism for this: the local issue tracker logic. But it's still a non-trivial amount of work.

Probably this should be done after #3897.

[timmaxw]

Actually, there's a lazier way to do it: when the user requests the current_issues table, we can fetch the configuration of every table over the network, then analyze it for issues on the machine that's reporting to the user. This would require a lot less development effort than the alternative.

[timmaxw]

Table configuration issues we need to report:

• Some server(s) listed in the config are unavailable, but the table is still available for reads and writes.
• The table is unavailable for writes, but auto-failover should kick in any second now.
• We've lost a quorum for one or more shards, so auto-failover is impossible and we can't perform writes (on this side of the netsplit, anyway). Variant: we've also lost a quorum for the table as a whole.
• None of the servers hosting the table are available, so we couldn't even fetch the config.
• All servers are available, but the table's write ack setting is too high to be satisfiable for some shards, so the table is not available for writes.

For any given table we should report at most one of the above issues. If multiple issues apply for different shards, we should report whichever one is more severe. We're already doing something similar in 2.0, but the details of the issues and how to detect them are different.

[Tryneus]

Working on this.

[Tryneus]

Up in review 2904.

[Tryneus]

This has been approved and merged into raft in commit 664657a.