Add support for TLS when connecting from client to amqproxy

[jwage]

We want to run amqproxy as a standalone service instead of running it locally on each client. Right now it appears that amqproxy only supports TLS on the amqproxy -> RabbitMQ side, and does not support TLS for client -> amqproxy connections. This prevents us from safely exposing amqproxy as a network service.

Is your feature request related to a problem? Please describe.

Without inbound TLS, clients connecting to amqproxy must either:

• Communicate in plaintext, or
• Be deployed inside a tightly controlled private network (VPC peering, PrivateLink, IPSec, etc.)

This limits flexibility and makes it difficult to operate amqproxy as a shared or remote proxy service in production. We’d like to avoid running a local amqproxy instance beside every client application and in some cases it's not possible for us currently.

Describe the solution you'd like

Add TLS configuration support to amqproxy’s server listener so that inbound client connections can be secured.

Describe alternatives you've considered

• Running all clients within a secured private network. We are investigating this option to solve our problem in the short term.
• Running amqproxy locally per client. We may be able to do this in the future, but right now we need to run amqproxy as a standalone service that our different compute services will communicate to RabbitMQ through.

[carlhoerberg]

What's you use case? afaik AMQProxy only shines when deployed very close to the client. If you introduce latency between amqproxy and your client you're back to square one again and it's questionable which benefit amqproxy will get you. But maybe you use amqproxy in a way we haven't foreseen. Maybe you're not in a Kubernetes context, but there, running amqproxy in a sidecar container is "best practice".