Some rexi and reshard parameters

Issue: https://github.com/apache/couchdb/issues/2457

Includes configure changes and Jenkins setting change.

Noticed mem3_sync_event_listner tests still fails intermetently, add a debug
log to it to hopefully find the cause of the failure.

Previously any failed node or rexi worker error resulted in requests failing
immediately even though there were available workers to keep handling the
request. This was because the progress check function didn't account for the
fact that partition requests only use a handful of shards which, by design, do
not complete the full ring.

Here we fix both partition info queries and dreyfus search functionality. We
follow the pattern from fabric and pass through a set of "ring options" that
let the progress function know it is dealing with partitions instead of a full
ring.

Adjust way to detect presence of hastings for Ken

After moving ken from https://github.com/apache/couchdb-ken to
https://github.com/apache/couchdb/tree/master/src/ken. The directory
structure related to ken is changed for downstream including Cloudant.
Increase more way to detect presence of hastings for Ken so that
Ken can work correctly for geospatial index.

Adds a new configuration field, `couch_httpd_auth.same_site` which
sets the `SameSite` attribute of the CouchDB auth cookie. If no
value is set (the default), no `SameSite` attribute is added.

Refs #2221

Previously we made sure replication job statistics were preserved when
the jobs were started and stopped by the scheduler. However, if a db
node restarted or user re-created the job, replication stats would be
reset to 0.

Some statistics like `docs_read` and `docs_written` are perhaps not as
critical. However `doc_write_failures` is. That is the indicator that
some replication docs have not replicated to the target. Not
preserving that statistic meant users could perceive there was a data
loss during replication -- data was replicated successfully according
to the replication job with no write failures, user deletes source
database, then some times later noticed some of their data is missing.

These statistics were already logged in the checkpoint history and we
just had to initialize a stats object from them when a replication job
starts. In that initialization code we pick the highest values from
either the running scheduler or the checkpointed log. The reason is
that the running stats could be higher if say job was stopped suddenly
and failed to checkpoint but scheduler retained the data.

Fixes: #2414

Previously if batch of bulk docs had to be bisected in order to fit a lower max
request size limit on the target, we only counted stats for the second batch.
So it was possibly we might have missed some `doc_write_failures` updates which
can be perceived as a data loss to the customer.

So we use the handy-dandy `sum_stats/2` function to sum the return stats from
both batches and return that.

Issue: https://github.com/apache/couchdb/issues/2414