This extends the existing http parser to support requests as well as responses.
httpcli continues to exist and work as it has previously, though in the new
directory src/core/http (to reflect the fact the directory now contains code
relevant to parsing requests, which httpcli would not generally involve itself
in).
On python3, in grpc._links.service._Kernel._on_service_acceptance_event,
there is a runtime TypeError:
```
_on_service_acceptance_event
group, method = service_acceptance.method.split('/')[1:3]
TypeError: 'str' does not support the buffer interface
```
It is fixed by using a bytes literal (`b'/'`) instead of a string literal.
This exposed another issue in grpc.beta._server where an exception was being
raised with a bytes literal for a message (a string should be used instead.)
Currently ByteBuffer.bytes() reads from the underlying grpc byte_buffer
a slice at a time, and appends each to a Python string (bytes). In
Python strings are immutable, so appending creates a new string by
copying the previous data. This means the current implementation is
quadratic.
The effect is very noticeable when messages have repeated (or large)
string fields. We traced execution between two services and observed
that when the payload size approached 600kb, the receiving service took
~10s at full CPU to read a response that had taken fractions of a second
the send over the network.
This commit changes ByteBuffer.bytes() to use an intermediate bytearray,
instead of strings, for the in-progress bytes. Once all slices are
read, the buffer is converted to a string.
When the connectivityMonitor determines the connection has been lost, pull the host disconnect call. Creates an unreliable connection when connectivity is restored. Calling finishWithError: is sufficient.
payload config in our server config. This affect any generic server
tests that use anything other than 0-byte responses: essentially,
server-streaming or bidi throughput tests.