Support multi-character delimiters

[Tim Burke]

Apparently this is something AWS supports, and it should be doable for us to do it, too.

Currently, an S3 client including a multi-char delimiter causes the container server to respond 412, which s3api completely chokes on, logs a traceback, and returns 500.

Note that this has some nice knock-on benefits for general Unicode support: since we previously required that delimiters be both a single-byte and valid UTF-8, we limited delimiters to just ASCII. With multi-character delimiters, we could allow any UTF-8 string.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/609843
Committed: https://git.openstack.org/cgit/openstack/swift/commit/?id=1ded0d6c8793ca3eca573c098cef78b5ae41f080
Submitter: Zuul
Branch: master

commit 1ded0d6c8793ca3eca573c098cef78b5ae41f080
Author: Tim Burke <email address hidden>
Date: Thu Oct 11 15:23:39 2018 -0700

    Allow arbitrary UTF-8 strings as delimiters in listings

    AWS seems to support this, so let's allow s3api to do it, too.

    Previously, S3 clients trying to use multi-character delimiters would
    get 500s back, because s3api didn't know how to handle the 412s that the
    container server would send.

    As long as we're adding support for container listings, may as well do
    it for accounts, too.

    Change-Id: I62032ddd50a3493b8b99a40fb48d840ac763d0e7
    Co-Authored-By: Thiago da Silva <email address hidden>
    Closes-Bug: #1797305

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/swift 2.23.0 release.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: feature/losf
Review: https://review.opendev.org/686864

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/686864
Committed: https://git.openstack.org/cgit/openstack/swift/commit/?id=bfa8e9feb51f2b10adfec3a741661a76fcf73216
Submitter: Zuul
Branch: feature/losf

commit cb76e00e90aea834c8f3dd8a6ca5131acd43663b
Author: OpenStack Proposal Bot <email address hidden>
Date: Fri Oct 4 07:05:07 2019 +0000

    Imported Translations from Zanata

    For more information about this automatic import see:
    https://docs.openstack.org/i18n/latest/reviewing-translation-import.html

    Change-Id: I40ce1d36f1c207a0d3e99a3a84a162b21b3c57cf

commit 527a57ffcdefc03a5080b07d63f0ded319e08dfe
Author: OpenStack Release Bot <email address hidden>
Date: Thu Oct 3 16:35:36 2019 +0000

    Update master for stable/train

    Add file to the reno documentation build to show release notes for
    stable/train.

    Use pbr instruction to increment the minor version number
    automatically so that master versions are higher than the versions on
    stable/train.

    Change-Id: Ia93e0b690f47c6231423a25dfd6a108a60378a21
    Sem-Ver: feature

commit 8a4becb12fbe3d4988ddee73536673d6f55682dd
Author: Tim Burke <email address hidden>
Date: Fri Sep 27 15:18:59 2019 -0700

    Authors/changelog for 2.23.0

    Also, make some CHANGELOG formatting more consistent.

    Change-Id: I380ee50e075a8676590e755f24a3fd7a7a331029

commit bf9346d88de2aeb06da3b2cde62ffa6200936367
Author: Tim Burke <email address hidden>
Date: Thu Aug 15 14:33:06 2019 -0700

    Fix some request-smuggling vectors on py3

    A Python 3 bug causes us to abort header parsing in some cases. We
    mostly worked around that in the related change, but that was *after*
    eventlet used the parsed headers to determine things like message
    framing. As a result, a client sending a malformed request (for example,
    sending both Content-Length *and* Transfer-Encoding: chunked headers)
    might have that request parsed properly and authorized by a proxy-server
    running Python 2, but the proxy-to-backend request could get misparsed
    if the backend is running Python 3. As a result, the single client
    request could be interpretted as multiple requests by an object server,
    only the first of which was properly authorized at the proxy.

    Now, after we find and parse additional headers that weren't parsed by
    Python, fix up eventlet's wsgi.input to reflect the message framing we
    expect given the complete set of headers. As an added precaution, if the
    client included Transfer-Encoding: chunked *and* a Content-Length,
    ensure that the Content-Length is not forwarded to the backend.

    Change-Id: I70c125df70b2a703de44662adc66f740cc79c7a9
    Related-Change: I0f03c211f35a9a49e047a5718a9907b515ca88d7
    Closes-Bug: 1840507

commit 0217b12b6d7d6f3727a54db65614ff1ef52d6286
Author: Matthew Oliver <email address hidden>
Date: Wed Sep 4 14:30:33 2019 +1000

    PDF Documentation Build tox target

    This patch adds a `pdf-docs` tox target that will build
    PDF versions of our docs. As per the Train community goal:

      https://governance.openstack.org/tc/goals/selected/train/pdf-doc-...