Make multidb changes shard map aware

[nickva]

couch_multidb_changes module is monitoring shards whose names match a particular suffix, and notifies users with found, updated and deleted events. This is the module which drives replicator jobs when */_replicator databases are updated.

Previously, couch_multidb_changes reacted only to node-local shard file events and was not aware of the shard map membership of those files. This was mostly evident during shard moves: the target shard could be created long before the
shard file becomes a part of the shard map. The replicator could notice the new target shard file and spawn a replication job on the new node, but keep the same replication job running on the source node. The two replication jobs will eventually conflict in the PG system (https://www.erlang.org/doc/man/pg.html) and one of them would start crashing with a "duplicate job" error. This could last days depending on how long it would take to populate the data on the target. Even after recovery, the target shard could be backed-off up to another extra 8 hours until it may run again.

To avoid issues like that, make couch_multidb_changes aware of shard map membership updates. When a shard file is discovered, and it is not in the shard map, mark it with a wait_shard_map = true flag. Then, re-use the existing db event monitoring mechanism to notice when shards db is updated, and schedule a delayed membership check for the shards tracked in our ETS table.

Other changes to the module are mostly cosmetic:

• Remove the unused created callback. db_found is used instead, both when dbs are created, and during startup when they are discovered.

• In the ETS table use a proper #row{} record since we now have 5 items in the tuple. This simplifies some of the existing code as well.

• During deletion and creation, actually delete the entries from the ETS table. Previously we didn't do it so the would hang around forever until the node was restarted.

• Add comments to a few tricky sections explaining what should be happening there.

• Add more tests, both the old and new functionality. Increase coverage from 96% to 98%.

[jaydoane]

Very nice cleanup on some super complex code!

[nickva]

After manually trying a few shard moves locally, the default scheduler interval seemed a bit long. It would be nice on average to react a bit quicker to shard map changes so decided to use {shards_db_check_msec, Interval div 2} instead of {[skip_ddocs, {dbs_check_msec, Interval}}. This way the shard map checks happens at least once before each scheduling interval.