Remove the requirement that messages conform to GRPCPayload on the server (#886)
Motivation:
To support payloads other than `SwiftProtobuf.Message` we required that
all messages conform to `GRPCPayload`. For protobuf messages we added
`GRPCProtobufPayload` which provides a default implemenation of
`GRPCPayload` for protobuf messages. We generated this conformance for
all protobuf messages we saw. This lead to a number issues and
workarounds including: #738, #778, #801, #837, #877, #881.
The intention is to continue to support `GRPCPayload` in addition to
protobuf, however, support for protobuf will not be via the
`GRPCProtobufPayload` protocol.
This PR adjusts server components such that they are not constrained to
`GRPCPayload`. At the moment only `SwiftProtobuf.Message` is supported.
Once the client side has had the same treatment and
`GRPCProtobufPayload` no longer inherits from `SwiftProtobuf.Message`,
support for `GRPCPayload` will be added back.
Modifications:
- The `HTTP1ToGRPCServerCodec` has had the message encoding and decoding
removed. It now deals in `ByteBuffer`s rather than request/response
messages.
- An additional `GRPCServerCodecHandler` which sits between the
`HTTP1ToGRPCServerCodec` and `_BaseCallHandler` has been added which
serializes/deserializes messages.
- Custom payload tests have been commented out. They will return when
the transition has completed.
Result:
- Servers only support SwiftProtobuf
- Genertic constraints on the server have been removed; the constraints
are place on the `init` of public handlers instead.
- `GRPCProtobufPayload` is no longer required on the server.
George Barnett