fix: added service entry for sentinel port on headless pods (#56)

## Description

This allows sentinels to be listed individually and accessed that way by
the client rather than being behind the service. GitLab didn't work when
accessing via the service, but did work when hitting the nodes directly.

This has been tested in that it's the version of the package I deployed
locally for testing the integration with GitLab.

## Related Issue


defenseunicorns/uds-bundle-software-factory-nutanix#220

## Type of change

- [X] Bug fix (non-breaking change which fixes an issue)

## Checklist before merging

- [ ] Test, docs, adr added or updated as needed
- [X] [Contributor Guide
Steps](/~https://github.com/defenseunicorns/uds-package-valkey/blob/main/CONTRIBUTING.md#developer-workflow)
followed

chart/templates/networking.yaml

@@ -18,6 +18,9 @@ spec:
     - number: 6379
       name: redis
       protocol: TCP
+    - number: 26379
+      name: sentinel
+      protocol: TCP
   location: MESH_INTERNAL
   resolution: NONE
 ---

docs/configuration.md

@@ -77,12 +77,12 @@ packages:
 This high-availability configuration will result in a few changes, some obvious, some less obvious:
 
 1. The single `valkey-master` pod will be replaced by pods named `valkey-node-0`, `valkey-node-1`, and so on per the requested number of `replicas`.
-2. Every `valkey-node` pod will now includes a Sentinel sidecar. It is accessed by contacting the valkey service at the Sentinel port `26379` rather than the read/write port `6379`.
+2. Every `valkey-node` pod will now includes a Sentinel sidecar. It is accessed by contacting the valkey service at the Sentinel port `26379` rather than the read/write port `6379`. It can also be accessed headlessly at `valkey-node-0.valkey-headless.<valkey namespace>.svc.cluster.local:26379`.
 3. As may be guessed from those two changes, the valkey service name also changes from `valkey-master.<valkey namespace>.svc.cluster.local` to, depending on your use-case:
 
-    - `valkey.<valkey namespace>.svc.cluster.local:26379` if trying to access a Sentinel.
+    - `valkey.<valkey namespace>.svc.cluster.local:26379` or the headless pod addresses if trying to access a Sentinel.
     - `valkey.<valkey namespace>.svc.cluster.local:6379` if trying to _read_ data.
-    - `valkey-node-<?>.valkey-headless.<valkey namespace>.svc.cluster.local:6379` if trying to _write_ data.
+    - `valkey-node-<?>.valkey-headless.<valkey namespace>.svc.cluster.local:6379` if trying to _write_ data as given by asking a Sentinel for the primary node's address.
 
       > Note the `<?>` in that address. The write node (called the Primary node) is only known by asking a Sentinel for the address and can change dynamically. Calling the sentinel to know where the primary node is should be handled by the calling application and so not relevant to most bundle development. If a Redis-ready application is given the address of the Sentinel service and the _read_ service that should be enough. For further clarity, see the Redis or Valkey documentation and review the tests for this application package where the Valkey CLI is used to communicate with both the standalone and replicated instances defined in the test bundle.