Update administrative tables docs and API docs for 2.1

[danielmewes]

table_config and table_status have changed slightly in the raft version.

The API docs for reconfigure, config and status will also need to be updated (their outputs have changed and we only allow single or majority write_acks).

There will probably be a few additional changes to accommodate rethinkdb/rethinkdb#3893 and rethinkdb/rethinkdb#3891 .

[timmaxw]

• There are two changes to rethinkdb.table_config (and r.table().config() too, of course):

  • Each shard subdocument of rethinkdb.table_config now has a new field called nonvoting_replicas. It must be a subset of the existing replicas field. It may be empty, or omitted, in which case it's treated as empty. The primary replica must not be a nonvoting replica.
  • The write_acks field must be "single" or "majority"; it is no longer allowed to be a list of more detailed specifications.

  Here's an example of what a table_config document looks like now:

  {
      id: "3fd6c63b-d184-4208-bc6e-e9add903c300",
      db: "test",
      name: "hi",
      primary_key: "id",
      shards: [
          {
              replicas: ["companion_cube"],
              primary_replica: "companion_cube",
              nonvoting_replicas: []
          }
      ],
      durability: "hard",
      write_acks: "majority"
  }

• reconfigure() has a new optarg nonvoting_replica_tags. Replicas with these tags will be put in the nonvoting_replicas list of the resulting config. For example, one might write:

  table.reconfigure({
      shards: 2,
      replicas: {"us_east": 2, "us_west": 1},
      primary_replica_tag: "us_east",
      nonvoting_replica_tags: ["us_west"]})

  The reconfigure command has also been overloaded to support emergency repair functionality. This is triggered by a new optarg emergency_repair, which will be documented elsewhere.

• There are two major changes to rethinkdb.table_status (and r.table().status() too):

  • The primary_replica field is now a list of zero, one, or multiple servers, called primary_replicas. If it contains multiple servers, that means that different parts of the shard are being served by different primaries. This is a temporary condition.
  • The possible values of the state field have changed. The new values are as follows:
    • ready, transitioning: The same as before.
    • backfilling: Same as the old backfilling_data.
    • disconnected: Same as the old missing.
    • waiting_for_primary: Same as the old looking_for_primary.
    • waiting_for_quorum: The primary is waiting for a quorum of the table's replicas to be available before it starts accepting writes.

  Here's an example of what a table_status document looks like now:

  {
      id: "3fd6c63b-d184-4208-bc6e-e9add903c300",
      db: "test",
      name: "hi",
      shards: [
          {
              replicas: [
                  {server: "companion_cube", state: "ready"}
              ],
              primary_replicas: ["companion_cube"]
          }
      ],
      status: {
          all_replicas_ready: true,
          ready_for_outdated_reads: true,
          ready_for_reads: true,
          ready_for_writes: true
      }
  }

[timmaxw]

We should explain non-voting replicas more clearly. #770 (comment) describes what the meaning of a "non-voting" replica is. The main reason to make a replica non-voting is to reduce latency if the replica is located in a faraway datacenter. One might want to set all of the replicas in one data center as voting, but all replicas in other datacenters as non-voting, so that their increased latencies don't slow down queries.