005 filter api to expose client and server tls info

[tombentley]

It's been suggested to break #71 into separate proposals to simplify review etc. This PR adds a "proposal" for exposing the client and server TLS information to filters.

[tombentley]

@robobario updated, if you wanted to take another pass.

[tombentley]

@k-wall @SamBarker please can you take a look at this. I'm very aware that we've already implemented half of it. It would be good to keep this repo aligned with (or at least not behind) what's actually implemented.

[k-wall]

I agree with @robobario's comment, but otherwise LGTM

[SamBarker]

I'm 100% happy with the gist of the proposal. My only objection as usual is the use of client and server, they should be downstream and upstream

[SamBarker]

I was wondering about changing server to broker here but then remembered we want to retain the idea we can proxy controllers as well so we are back to the usual upstream vs server argument.

I still think upstream is clearer and entirely unambiguous where as server is not.

[SamBarker]

While I have fewer issues with calling this ClientTlsContext than I do with ServerTlsContext I think this is better named DownstreamTlsContext.

[SamBarker]

Upstream clearly conveys that it is the remote certificate and avoids needing to talk about Kafka server which is not normal parlance when discussing Kafka.

Suggested change

	/**
	* @return the TLS server certificate was presented by the Kafka server to the proxy during TLS handshake.
	*/
	X509Certificate serverCertificate();
	/**
	* @return the TLS server certificate was presented by the remote Kafka process to the proxy during TLS handshake.
	*/
	X509Certificate upstreamCertificate();