Make deleting recovery.conf optional. (#638)

pgBackRest's restore command generates the appropriate recovery.conf based
on the parameters you provide to pgBackRest.  When calling pgBackRest's restore command
via Patroni's custom bootstrap, it deletes that recovery.conf.  Specifying the recovery.conf
information in the patroni.yml is less than ideal.  It prevent's leveraging pgBackRests
work to ensure recovery.conf files are properly generated.  It also can lead to transient
config data in the patroni.yml under certain restore cases, such as a PITR restore
of Cluster B to  Cluster A, where the restore_commnand in A needs to reference B.

The parameter is optional.  The default behavior is to delete the recovery.conf.

Fixes https://github.com/zalando/patroni/issues/637

docs/replica_bootstrap.rst

@@ -23,6 +23,7 @@ arguments to them, i.e. the name of the cluster and the path to the data directo
         method: <custom_bootstrap_method_name>
         <custom_bootstrap_method_name>:
             command: <path_to_custom_bootstrap_script> [param1 [, ...]]
+            keep_existing_recovery_conf: False
             recovery_conf:
                 recovery_target_action: promote
                 recovery_target_timeline: latest
@@ -47,6 +48,9 @@ If a ``recovery_conf`` block is defined in the same section as the custom bootst
 ``recovery.conf`` before starting the newly bootstrapped instance. Typically, such recovery.conf should contain at least
 one of the ``recovery_target_*`` parameters, together with the ``recovery_target_timeline`` set to ``promote``.
 
+If ``keep_existing_recovery_conf`` is defined and set to ``True``, Patroni will not remove the existing ``recovery.conf`` file if it exists.
+This is useful when bootstrapping from a backup with tools like pgBackRest that generate the appropriate ``recovery.conf`` for you.
+
  .. note:: Bootstrap methods are neither chained, nor fallen-back to the default one in case the primary one fails