Add support for multiple values for the x-forwarded-proto header

[vanschelven]

See #2102

When uvicorn is deployed behind more than one proxy, the proxy behavior is sometimes to list the protocol as a comma-separated list.

However, currently, uvicorn expects only one value for the x-forwarded-proto header, instead of parsing it as a list of values and setting the protocol accordingly.

x-forwarded-proto is a non-standard header, so there isn't a specification for its use, but different reverse-proxy vendors do use it in different ways, and some append the protocol as a comma-separated value from left-to-right (left being the furthermost proxy and rightmost being the closest).

Checklist

• I understand that this PR may be closed in case there was no previous discussion. (This doesn't apply to typos!)
• I've added a test for each change that was introduced, and I tried as much as possible to make a single atomic change.
• I've updated the documentation accordingly.
• I'm a volunteer myself who's happy to provide a drive-by commit as a direction for a solution but cannot spend more time on this right now

[Kludex]

I don't see much literature about receiving a comma-separated list. The main references I could find have either "https" or "http".

[vanschelven]

Do you not consider the list in the linked resource sufficiently authoritative enough or did you perhaps miss it? Quoted below: Similar issues have been raised and implemented in other projects, for example: Tornado: - Issue: ​tornadoweb/tornado#2161 <tornadoweb/tornado#2161> - Implementation: ​https://github.com/tornadoweb/tornado/blob/00c9e0ae31a5a0d12e09109fb77ffe391bfe1131/tornado/httpserver.py#L347-L350 <https://github.com/tornadoweb/tornado/blob/00c9e0ae31a5a0d12e09109fb77ffe391bfe1131/tornado/httpserver.py#L347-L350> Ruby: - Issue: ​https://bugs.ruby-lang.org/issues/10789 <https://bugs.ruby-lang.org/issues/10789> - Implemenation: ​https://github.com/ruby/ruby/blob/d92f09a5eea009fa28cd046e9d0eb698e3d94c5c/tool/lib/webrick/httprequest.rb#L614-L616 <https://github.com/ruby/ruby/blob/d92f09a5eea009fa28cd046e9d0eb698e3d94c5c/tool/lib/webrick/httprequest.rb#L614-L616> Reactor-Netty: - ​reactor/reactor-netty#976 <reactor/reactor-netty#976> - Implementation: ​reactor/reactor-netty@e190d5b <reactor/reactor-netty@e190d5b> [..] Common example of this behavior is when using mulitple AWS proxies such as API Gateway proxying to an elastic load balancer.