Comment 1 for bug 2040178

Reviewed: https://review.opendev.org/c/openstack/swift/+/896466
Committed: https://opendev.org/openstack/swift/commit/3dab88bdf83eba339cd1a2d391b9e421ff2c5cf0
Submitter: "Zuul (22348)"
Branch: master

commit 3dab88bdf83eba339cd1a2d391b9e421ff2c5cf0
Author: Clay Gerrard <email address hidden>
Date: Fri Sep 22 14:48:41 2023 -0500

    tests: refactor SLO size/etag sysmeta tests

    We've been writing SLO manifests with size/etag sysmeta for more than 5
    years, but we want our tests and code to continue to support the legacy
    format forever. This test infra refactor will make that easier for test
    authors to opt-in testing of legacy manifests by reusing a common
    pattern for manifest setup across tests.

    This consolidation also cleans up some duplication where two TestCases
    had identical manifest setup and paves the way to more tidying of
    similar (but slightly different) manifest setup across TestCases and
    sharing of setup across future TestCases.

    This manifest setup standardization also adopts a consistent naming
    scheme for manifest sysmeta values so test assertions are easier to read
    as correct at a glance (e.g. slo_etag vs json_md5)

    Additionally leak tracking is added to the common base; SLO was already
    really good about *closing* requests, but in many cases seems to not
    bother reading/draining them (even when they might be empty/small).

    As part of the leak tracking investigation a couple new tests were added
    to explore the behavior of SLO's SegmentedIterable in the
    request_helpers module.

    Drive-By: Fix SegmentedIterable docstring: the constructor has
    expected an iterable yielding dicts, not tuples, since the
    Related-Change [2].

    Drive-By: remove FakeSwift's now unused "register_responses" interface
    and provide "register_next_response" as a replacment. This allows test
    authors to extend the registered response for a given request key from a
    common test setup into a "series of registered responses" by expressing
    just the new/next response rather than forcing them to duplicate the
    initial response in the explicit list passed to "register_responses".

    Related-Bug: #2040178
    Co-Authored-By: Alistair Coles <email address hidden>
    [1] Related-Change: Ia6ad32354105515560b005cea750aa64a88c96f9
    [2] Related-Change-Id: Ib8dc216a84d370e6da7d6b819af79582b671d699
    Change-Id: I54094f3d2098f56b755ec19cc9315d06a6ca8b15