## Description

_Describe the big picture of your changes here to communicate to the maintainers why we should accept this pull request._

_If it fixes an existing issue (bug or feature), use the following keyword:_

_Closes: #ISSUE-NUMBER_

## Type of change

_What type of changes does your code introduce to the Prometheus operator? Put an `x` in the box that apply._

- [ ] `CHANGE` (fix or feature that would cause existing functionality to not work as expected)
- [ ] `FEATURE` (non-breaking change which adds functionality)
- [ ] `BUGFIX` (non-breaking change which fixes an issue)
- [ ] `ENHANCEMENT` (non-breaking change which improves existing functionality)
- [ ] `NONE` (if none of the other choices apply. Example, tooling, build system, CI, docs, etc.)

## Verification
<!-- How you tested it? How do you know it works? -->
Please check the [Prometheus-Operator testing guidelines](../TESTING.md) for recommendations about automated tests.

## Changelog entry

_Please put a one-line changelog entry below. This will be copied to the changelog file during the release process._

<!-- 
Your release note should be written in clear and straightforward sentences. Most often, users aren't familiar with
the technical details of your PR, so consider what they need to know when you write your release note.

Some brief examples of release notes:
- Add metadataConfig field to the Prometheus CRD for configuring how remote-write sends metadata information.
- Generate correct scraping configuration for Probes with empty or unset module parameter.
-->

```release-note

```
