Use rexi:stream/1 for view backpressure

This uses the new rexi:stream/1 API to allow rexi workers to stream
results back to the coordinator process. This is intended to reduce the
sensitivity of views to RTT between nodes involved in a view response.
Make sure and cleanup spawned db update listeners

The showroom_users_cache changes feed `exit`'s ever so often to avoid
"getting stuck". The propogation of the `exit` signal ended up killing
the fabric_db_update_listener process before it had a chance to cleanup
the processes it spawned on remote nodes.

This patch adds a process that traps exits and calls the cleanup
regardless of how the fabric_db_update_listener finishes (by returning
or if the process disappears). This should fix most of the issue
although it does not fix the issue if the VM dissappears instantaneously
(ie, segfault). For that we need to add something on the remote side
that will flush rexi processes when a node disappears.
Merge pull request #54 from cloudant/14082-cleanup-db-update-listeners

BugzID: 14082
Set an endkey when pulling design docs

Omitting the endkey causes the system to walk all deleted documents
looking for the next non-deleted one.  This is very expensive on
databases with lots of deletions.

BugzID: 14636
Merge pull request #58 from cloudant/14636-use-endkey-for-design-docs

Set an endkey when pulling design docs

BugzID: 14636
Provide a shards option to fabric:get_all_security

To trigger syncing security objects we want to be able to just compare
the local shard object to the remote. This change allows us to just
specify a list of shards to request so we don't needlessly get values
for all shards.

BugzId: 11602
Refactor fabric calls for security objects

Instead of relying on global consistency for success we relax
constraints to only require a simple majority of shards to return
values. In the case of set_security we also require that a complete hash
ring returned successfully before indicating success to the client.

BugzId: 11602
One ok implies acceptance

A mixed response of [ok,conflict,conflict] is usually a conflict
response. This patch changes it to an 'accepted' response, since one
of the writes did happen. On high throughput clusters we have observed
spurious [ok,conflict,conflict] responses due to the race with the
internal replicator.

BugzID: 14833
Remove unreachable clause
Merge pull request #61 from cloudant/14833-spurious-conflict

BugzID: 14953
Merge pull request #60 from cloudant/11602-sync-security

BugzID: 11602
Revert "Merge pull request #61 from cloudant/14833-spurious-conflict"

This reverts commit 13f256c807d02cbcca1da2fbcda85c29c119518a, reversing
changes made to 86ce90c476b239df560f2432c96e8623047fdd41.
Only consider success responses in quorum check

BugzID: 14953
Merge pull request #62 from cloudant/14953-spurious-conflict

Fix spurious conflicts by only considering 'ok' responses in quorum check

BugzID: 14953
Don't attempt to handle db update listener errors

It doesn't make too much sense to attempt to continue listening for
update notifications when workers have crashed. If we don't have
listeners configured we may be missing events and lying to clients about
that.

While it would be technically possible to withstand some level of error
using a scheme similar to `fabric_view:is_progress_possible/1` such an
approach only prolongs the inevitable crash because we can't easily add
workers back to our `rexi_utils:recv/6` loop to heal from such errors.

I've also refactored a bit to use records so that variables are more
clearly marked.
Optimize db update notifications

This reduces the number of handlers that need to be registered on each
node by the number of shards it hosts. Instead of a handler for each
shard we just register one and use lists:member/2 to check if we care
about each update message.

BugzId: 13600
Bump meck version to support E15 builds. BugzID: 15010
Merge pull request #56 from cloudant/13600-optimize-update-notifications

Optimize db update notifications

BugzID: 13575
BugzID: 13600
Consider 'noreply' as a success for quorum check

The new_edits:false option suppresses responses.  We need to account for
that fact when tabulating success replies for the quorum check.  This
fixes a regression in Hodge.

BugzID: 15358
BugzID: 14953
Merge pull request #63 from cloudant/15358-replicator-writes-quorum-regression

Consider 'noreply' as a success for quorum check

BugzID: 15358