container-sharder should send stat updates using replication network

[Tim Burke]

Currently it uses the client-facing network, which seems wrong.

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.opendev.org/735991

[OpenStack Infra (hudson-openstack)]

Change abandoned by Tim Burke (<email address hidden>) on branch: master
Review: https://review.opendev.org/735991
Reason: Squashed into parent.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/735751
Committed: https://git.openstack.org/cgit/openstack/swift/commit/?id=2a6dfae2f3d50750de2bdb5f31ea52070588e895
Submitter: Zuul
Branch: master

commit 2a6dfae2f3d50750de2bdb5f31ea52070588e895
Author: Tim Burke <email address hidden>
Date: Mon Jun 15 17:09:15 2020 -0700

    Allow direct and internal clients to use the replication network

    A new header `X-Backend-Use-Replication-Network` is added; if true, use
    the replication network instead of the client-data-path network.

    Several background daemons are updated to use the replication network:

      * account-reaper
      * container-reconciler
      * container-sharder
      * container-sync
      * object-expirer

    Note that if container-sync is being used to sync data within the same
    cluster, the replication network will only be used when communicating
    with the "source" container; the "destination" traffic will continue to
    use the configured realm endpoint.

    The direct and internal client APIs still default to using the
    client-data-path network; this maintains backwards compatibility for
    external tools written against them.

    UpgradeImpact
    =============

    Until recently, servers configured with

      replication_server = true

    would only handle REPLICATE (and, in the case of object servers, SSYNC)
    requests, and would respond 405 Method Not Allowed to other requests.
    When upgrading from Swift 2.25.0 or earlier, remove the config option
    and restart services prior to upgrade to avoid a flood of background
    daemon errors in logs.

    Note that some background daemons find work by querying Swift rather
    than walking local drives that should be available on the replication
    network:

      * container-reconciler
      * object-expirer

    Previosuly these may have been configured without access to the
    replication network; ensure they have access before upgrading.

    Closes-Bug: #1883302
    Related-Bug: #1446873
    Related-Change: Ica2b41a52d11cb10c94fa8ad780a201318c4fc87
    Change-Id: Ieef534bf5d5fb53602e875b51c15ef565882fbff