BaseHTTPRequestHandler.parse_request() loses client-provided information

Bug report

The fix for https://github.com/python/cpython/issues/87389 prevents servers from handling request paths with multiple leading slashes.

For example, one might have a simple server that just reflects the request path:

from http.server import *

class MyHTTPRequestHandler(BaseHTTPRequestHandler):
    def do_GET(self):
        self.send_response(200)
        self.end_headers()
        self.wfile.write(self.path.encode('latin1'))

with ThreadingHTTPServer(('127.0.0.1', 8000), MyHTTPRequestHandler) as server:
    server.serve_forever()

Previously, this would faithfully mirror the request path from the client:

$ curl -v http://localhost:8000//test
*   Trying 127.0.0.1:8000...
* Connected to localhost (127.0.0.1) port 8000 (#0)
> GET //test HTTP/1.1
> Host: localhost:8000
> User-Agent: curl/7.82.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
* HTTP 1.0, assume close after body
< HTTP/1.0 200 OK
< Server: BaseHTTP/0.6 Python/3.8.13
< Date: Mon, 07 Nov 2022 21:51:19 GMT
< 
* Closing connection 0
//test

But now it mangles it:

$ curl -v http://localhost:8000//test
*   Trying 127.0.0.1:8000...
* Connected to localhost (127.0.0.1) port 8000 (#0)
> GET //test HTTP/1.1
> Host: localhost:8000
> User-Agent: curl/7.82.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
* HTTP 1.0, assume close after body
< HTTP/1.0 200 OK
< Server: BaseHTTP/0.6 Python/3.11.0
< Date: Mon, 07 Nov 2022 21:51:30 GMT
< 
* Closing connection 0
/test

This impacts any servers that subclass BaseHTTPRequestHandler, such as eventlet's WSGI server.

Start with BaseHTTPRequestHandler.parse_request() and compare its current handling of the //test request with the behavior shown in the report. Trace the change associated with issue 87389 and identify where the client-provided path is altered. Done means subclasses such as the example server can receive the original leading slashes without regressing request validation.