Misconfigured non-gRPC, HTTP/2 clients can sometimes connect to gRPC servers.

Today, these clients will receive an HTTP status 200 (OK) with a trailer that
gRPC clients would be able to interpret as an error, but non-gRPC clients would
interpret as a success.  In Go and Java, this will have a grpc-status of
UNKNOWN due to an unexpected content-type header.  In C, the content-type
header is currently ignored, but a grpc-status of UNAVAILABLE will be returned
if a handler for that method is not registered (which is likely in this
scenario).

This change updates the gRPC HTTP/2 spec to recommend returning HTTP status 400
(Bad Request) to interoperate better with non-gRPC clients.

Note that we should not do any enforcement on user-agent, as the spec
specifically says "the protocol does not require a user-agent to function".

doc/PROTOCOL-HTTP2.md

@@ -61,6 +61,8 @@ the form shown above.
 
 If **Timeout** is omitted a server should assume an infinite timeout. Client implementations are free to send a default minimum timeout based on their deployment requirements.
 
+If **Content-Type** does not begin with "application/grpc", gRPC servers SHOULD respond with HTTP status of 400 (Bad Request).  This will prevent other HTTP/2 clients from interpreting a gRPC error response, which uses status 200 (OK), as successful.
+
 **Custom-Metadata** is an arbitrary set of key-value pairs defined by the application layer. Header names starting with "grpc-" but not listed here are reserved for future GRPC use and should not be used by applications as **Custom-Metadata**.
 
 Note that HTTP2 does not allow arbitrary octet sequences for header values so binary header values must be encoded using Base64 as per https://tools.ietf.org/html/rfc4648#section-4. Implementations MUST accept padded and un-padded values and should emit un-padded values. Applications define binary headers by having their names end with "-bin". Runtime libraries use this suffix to detect binary headers and properly apply base64 encoding & decoding as headers are sent and received.
@@ -255,5 +257,3 @@ to be used.
 * **Service-Name** → ?( {_proto package name_} "." ) {_service name_}
 * **Message-Type** → {_fully qualified proto message name_}
 * **Content-Type** → "application/grpc+proto"
-
-