Support for mutual TLS for redis and postgres - #1020

Security is not optional in my organisation, so I extended the respective driver configuration code to handle full TLS verification and updated the sample configuration.

I think this applies to most ChirpStack deployments, however does TLS and username / password authentication solve most security considerations? It provides a secure channel + a way to provide authentication & authorization.

Maybe other users could comment on this if this is a feature that is needed (or not)?

I added support for the api endpoint as well, while i was at it. It could be done with a reverse proxy, but well :)

Concerning the username/password question, yes of course it serves the same purpose, but it means transferring secrets around. With mTLS, the secret never has to actually leave the server (or a hardware security module, if you really mean it), which increases overall security and is mandatory for certain regulated environments.

In my case it was actually easier to implement it right here in chirpstack than to build password management infrastructure for my fleet. It also resolves the issue mentioned here after the 4.7 release:

https://forum.chirpstack.io/t/release-chirpstack-v4-7/19219/8

I'll leave this open for a while to see if there is more interest in mTLS for the database backends. I have never used it / seen it before being used and it seems the major cloud providers providing managed database do not support this either.

I'm not saying mTLS for databases is a bad idea and there certainly might be uses-cases for it, but I'm trying to weight what should be merged into this project and what not. Sometimes features like this become problematic or time-consuming over the long run or make the configuration very verbose as we end up with many options that will never be used by the majority of its users.