Chart is not able to utilize Redis Sentinels when using internal Redis Cluster

As noted in #1519 (comment 270779238), the chart is not able to use the Redis sentinel support when it deploys a Redis cluster. Sentinel support is still available if the Redis cluster is created separately from the GitLab helm chart.

There is a name difference in the Redis service when sentinel support is activated. Without sentinel support, the Kubernetes Service name is <RELEASE>-redis-master-0. When sentinel support is turned on the Service name becomes <RELEASE>-redis. When configuring the Redis endpoints within the GitLab sub-charts it is not possible to interrogate redis.sentinel.enabled setting to determine which Service name to use.

At this point one option is to create a global helm setting that is unsynchronized with redis.sentinel.enabled to allow for the correct Service name to be chosen. This will probably lead to misconfigurations and problematic GitLab installs unless a mechanism can be found to synchronize or validate the configuration during installation and upgrades.

Another option that may work, but has not been proven yet, is to use redis.nameOverride. This may allow the Service name to be specified for all configurations, but it is uncertain how many other objects will be affected with this setting.