This removes invocation-side completion queues from the _cygrpc API.
Invocation-side calls are changed to no longer share the same lifetime
as Core calls.
Illegal metadata is now detected on invocation rather than at the start
of a batch (so passing illegal metadata to a response-streaming method
will now raise an exception immediately rather than later on when
attempting to read the first response message).
It is no longer possible to create a call without immediately starting
at least one batch of operations on it. Only tests are affected by this
change; there are no real use cases in which one wants to start a call
but wait a little while before learning that the server has rejected
it.
It is now required that code above cygrpc.Channel spend threads on
next_event whenever events are pending. A cygrpc.Channel.close method
is introduced, but it merely blocks until the cygrpc.Channel's
completion queues are drained; it does not itself drain them.
Noteworthy here is that we drop the cygrpc.Channel.__dealloc__ method.
It is not the same as __del__ (which is not something that can be added
to cygrpc.Channel) and there is no guarantee that __dealloc__ will be
called at all or that it will be called while the cygrpc.Channel
instance's Python attributes are intact (in testing, I saw both in
different environments). This commit does not knowingly break any
garbage-collection-based memory management working (or "happening to
appear to work in some circumstances"), though if it does, the proper
remedy is to call grpc.Channel.close... which is the objective towards
which this commit builds.
When initiating a connection to an IPv6 peer using an address that is
not globally scoped, there may be ambiguity regarding which zone the
destination address applies to when multiple links of the same scope
are present. The scoped address architecture and zone-id syntax are
described in rfc4007 and rfc 6874, respectively:
* https://tools.ietf.org/html/rfc4007#section-6
* https://tools.ietf.org/html/rfc6874
This patch allows host name verification performed during TLS session
establishment, and on a per-call basis, to work correctly when the peer
presents a certificate with a non-global IPv6 address listed as one of
its alternate names. Whether arbitrary certificate authorities choose
issue certificates of this nature, or not, is outside the scope of gRPC.
The zone-id is separated from the address using a percent (%) character.
It is considered a system implementation detail and guidance suggests it
be stripped from any paths or addresses egressing a host because it is
irrelevant and meaningless otherwise. It would not make sense for a
server to present a certificate containing non-global IPv6 addresses
with zone-ids present nor would it work unless two hosts happened to
be using the same zone-id.
ssl_host_matches_name is prefixed with grpc_ because it has been
promoted to the global namespace for testing.
Resolves#14371
This is purely for convenience - using `e.Status.StatusCode` looks
clunky compared with `e.StatusCode`, and this is the property most
likely to be used for exception filtering etc.