Update tests to use the new replicator. Also clean up redundancy and re-use
some of the newer macros from fabric2 (?TDEF_FE).

Make sure replicator tests are included in `make check`

Remove sections which don't apply anymore and describe briefly how frontend and
backend interact.

Update settings with defaults. Also comment out values which are already set to
default in the code.

Stich everything together: the backend, frontend and http handlers.

The supervisor `couch_replicator_sup` handles starting a set of fronted or
backend children. It may also start both or neither.

The HTTP layer for monitoring and creating jobs is simpler than before since
there is rpc and clustering involved.

Backend replicator modules execute replication jobs. The two main modules
reponsible for job management and execution are `couch_replicator_job` and
`couch_replicator_job_server`.

`couch_replicator_job`

 - Is the main process of each replication job. When this process starts, it
   waits in the `couch_jobs:accept/2` call. This may take an indefinite amount
   of time. The spawned `couch_replicator_job` waiting in accept like that is
   called internally an "acceptor". The main pattern of execution is multiple
   acceptors are started, and after some of them accept jobs, they become
   "workers".

 - After it accepts a job, it parses the `couch_jobs` job data, which contains
   the `Rep` object and calculates the replication ID from it. Replication ID
   calculation may involve making a call to the source endpoint in order to
   fetch the contents of the javascript filter. Then, the `Rep` object and the
   replication ID is used to construct the internal `#rep_state{}` state record
   of the `gen_server`.

 - Multiple replication jobs may end up trying to run the same replication
   (with the same replication ID) concurrently. To manage these types of
   colisions, `check_ownership/3` function is called to determine if the
   current replication is the correct `owner` of that replication. If it is
   not, then the job maybe fail and exit.

 - There is a periodic checkpoint timer which sends a `checkpoint` message. The
   checkpoint frequency is calculated as the minimum of the `couch_jobs`
   activity timeout and the configured checkpoint interval. During each
   checkpoint attempt, there is a call to `couch_jobs:update/3` which updates
   the job's data with latest state and ensure the job doesn't get re-enqueued
   due to inactivity.

 - If the job completes, then `couch_jobs:finish/3` is called and the
   replication process exits `normal`. If the job crashes, there is a
   consecutive error count field (`?ERROR_COUNT`) which, is used to calculate
   the backoff penalty. There is an exponential backoff schedule, that starts
   with the base value, then doubles, but only up to a maximum value. Both the
   base and the maximum values are configurable with the
   `min_backoff_penalty_sec` and `max_backoff_penalty_sec` settings
   respecively. This is an improvement from before where the users could only
   influence the maximum backoff penalty by reducing the number of failed
   events kept by each job.

`couch_replicator_server`

 - This is a module which spawns and keeps track of `couch_replicator_job`
   processes.

 - Periodically, every `interval_sec` seconds, it runs the `reschedule` function
   which checks for pending jobs. If they are some, it will start acceptors to
   run them. If those acceptors become workers, and if the total number of
   workers goes above the `max_jobs` setting, the oldest `continuous` workers
   will be stopped until the total number of jobs falls below `max_jobs` value.

 - In addition to `max_jobs` limit, there is a `max_churn` limit which
   determines up to how many job starts to allow during each scheduling
   interval. As jobs are started, they reduce the available churn "budget" for
   that cycle and after it goes below 0 no more jobs can start until the next
   cycle.

 - This module also performs transient job cleanup. After transient jobs stop
   running previously they simply vanished but with this update they maybe
   linger for at least `transient_job_max_age_sec` seconds.

The frontend is the part responsible for parsing replication parameters and
creating replication jobs. Most of that happens in the `couch_replicator`
module.

 - `couch_replicator:replicate/2` is the main API for creating transient
   replication jobs.

 - Replication jobs from `_replicator` documents are updated from
  `couch_replicator:after_*` callbacks. `after_db_create/2` besides being
  called on db creation also gets called when a database is undeleted and
  `add_jobs_from_db/1` function will attempt to parse them all.

`couch_replicator` exports monitoring functions `docs/2,3 and jobs/0,1`. Those
get called from HTTP handlers for `_scheduler/docs` and `_scheduler/jobs`
respectively.

For hands-on remsh access there some debuging functions such as:

 - rescan_jobs/0,1 : Simulates a db being re-created so all the jobs are added
 - reenqueue_jobs/0,1 : Deletes all the jobs from a db then re-adds them
 - remove_jobs/0 : Removes all the replication jobs
 - get_job_ids/0 : Read the RepId -> JobId mapping area

This is the `couch_jobs` abstraction module. All replicator calls to
`couch_jobs` should go through it. This module takes care of adding types to
some of the API calls, handles maintencence of the RepId -> JobId mappings when
jobs are added and removed, and some subscription logic.

`fabric2.hrl` include file is updated with the definition of the
`?REPLICATION_IDS` prefix where the RepId -> JobId keyspace lives.

This module is responsible for calculating replication IDs. It inspects all the
replication options which may affect the replication results and hashes them
into a single ID. CouchDB replicator tries to maintain compatibility with older
versions of itself so it keep tracks of how to calculate replication IDs used
by previous version of CouchDB. Replication ID calculation algorithms have
their own version, the latest one is at version 4.

One of the goals of this update is to not alter the replication ID algorithm
and keep it at version 4, such that for all the same parameters the replication
IDs should stay the same as they would be on CouchDB <= 3.x. That is why in
some internal function, options maps and binares are turned back into proplist
and tuples before hashing is performed. There is a unit tests which asserts
that the replication ID calcuated with this update matches what was calcuated
in CouchDB 3.x.

Internal representation of the replication ID has changed slighly. Previously
it was represented by a tuple of `{BaseId, ExtId}`, where `BaseId` was the ID
without any options such as `continuous` or `create_target`, and `ExtId` was
the concatenated list of those options. In most cases it was useful to operate
on the full ID and in only a few place the `BaseId` was needed. So the
calculation function was updated to return `{RepId, BaseId}` instead. `RepId`
is a binary that is the full relication ID (base + extensions) and `BaseId` is
just the base.

The function which calculated the base ID was updated to actually be called
`base_id/2` as opposed to `replication_id/2`.

Another update to the module is a function which calculates replication job
IDs. A `JobId` is used to identify replication jobs in the `couch_jobs` API. A
`JobId`, unlike a `RepId` never requires making a network round-trip to
calculate. For replications created from `_replicator` docs, `JobId` is defined
as the concatenation of the database instance UUID and document ID. For a
transient jobs it is calculated by hashing the source, target endpoint
parameters, replication options. In fact, it is almost the same as a
replication ID, with one important difference that the filter design doc name
and function name are used instead of the contents of the filter from the
source, so no network round-trip is necessary to calculate it.

The goal is to keep everything below the _api_wrap module level relatively
intact. To achieve that handle option maps in some places, or translate back to
a proplist or `#httpd{}` records in others.

The `couch_replicator_api:db_from_json/1` function is where endpoint map object
from a `Rep` object are translated into `#httpdb{}` records. Headers are
translated back to lists and ibrowse options into proplist with atom keys.