Configure Monitoring settings for OpenBao

Summary

To align with GitLab Chart standards for monitoring and enable users to scrap metrics with Prometheus operator.

Implementation design

Decision: Implement PodMonitor for OpenBao monitoring as the first iteration.

Implementation approach: Default to scraping all pods with configurable selector labels for customization.

**Rationale:**

Recap of #31 (comment 2902841151) with Duo help:

1. Complete pod lifecycle visibility - PodMonitor allows tracking pods through their full lifetime, including transitions between active/inactive states. This is valuable for observing metrics like memory usage and cache hit ramps when pods become active.

2. Avoids missing pods - ServiceMonitor only scrapes ready pods, which could result in missing metrics during pod state transitions or when pods are not ready. With OpenBao's HA architecture using active/inactive states, this limitation could create monitoring blind spots.

3. Flexible filtering - Users can differentiate between active/inactive pods using PromQL queries on the vault.core.active metric, providing the same granularity as multiple ServiceMonitors without the complexity.

4. Satisfies all scenarios - PodMonitor can be configured to scrape all pods by default while exposing additional selector labels, allowing admins to monitor only active pods on demand if needed.

5. Low overhead - Since OpenBao doesn't scale horizontally, the number of pods remains relatively low, so Prometheus scraping all pods won't create performance concerns.

6. Alignment with official chart - While the official OpenBao Helm chart uses ServiceMonitor selecting only active pods, PodMonitor provides more flexibility without significant drawbacks for our use case.

Success criteria

Monitoring settings for OpenBao are available to be used with Prometheus operator

TODO - update PREP to include requirement for PodMonitor or ServiceMonitor and same for Chart development guide