KAS chart: Add TLS to redis config where required

Summary

Currently if a Redis host that uses SSL is used for GitLab KAS, KAS will refuse to connect, citing an i/o timeout. A confusing error, but one that eventually resulted in testing whether disabling in-transit encryption on the Redis instance (actually an Elasticache instance), would allow KAS to connect and succeed, similarly to the rest of GitLab.

Steps to reproduce

Deploy KAS using our helm charts.

The user Redis config is as follows;

redis:
host: <elasicache-host>.cache.amazonaws.com
port: 6379
password:
enabled: true
secret: gitlab-redis-password
key: redis-password
scheme: rediss

Which results in GitLab using a connection string that is rediss://<elasicache-host>.cache.amazonaws.com:6379

If you go look at how the helm chart has configured KAS, the connection string is:

redis:
password_file: /etc/kas/redis/redis-password
server:
address: <elasticache-host>.cache.amazonaws.com:6379

which excludes rediss://.

Current behavior

The user can disable Redis for KAS to make KAS work for everything else.

Expected behavior

The chart should make use of the string, rediss:// specifically for cases that involve encrypted redis connections such as AWS Elasticache.

Relevant logs

Agent log:

{"level":"error","time":"2021-09-29T15:10:39.384Z","msg":"Error handling a connection","mod_name":"reverse_tunnel","error":"rpc error: code = ResourceExhausted desc = new connection rate limit exhausted for this agent, try again later","correlation_id":"XXXXXXXXXXXXXXXXX"}

Server log:

{"level":"error","time":"2021-09-29T15:11:32.929Z","msg":"redistool.TokenLimiter: error retrieving minute bucket count","correlation_id":"XXXXXXXXXXXXXXXXXX","grpc_service":"gitlab.agent.reverse_tunnel.rpc.ReverseTunnel","grpc_method":"Connect","error":"i/o timeout"}