Draft: Query for patch status with both versions and release_date

What does this MR do and why?

Fix for the edge case where on patch release publish day for the first patch release of the milestone, after finalize stage jobs are run and new metrics are created, it would fetch the older metric using the same versions in the query (since the two releases in the milestone share the versions, and not the release_date)

We should have more consistent fetch going forward now that we're fetching for the metric using releases_client.next_patch_release_date as well as the versions.

Timeline expectation vs reality overview

Timeline	Metrics present	Metric to refresh (expectation)	Metric that currently gets refreshed (reality)
On the day of release Before publishing	delivery_release_patch_status{versions="17.2 17.1 17.0", release_date="07-24-2024"} 3	delivery_release_patch_status{versions="17.2 17.1 17.0", release_date="07-24-2024"} 3	delivery_release_patch_status{versions="17.2 17.1 17.0", release_date="07-24-2024"} 3
After publishing	delivery_release_patch_status{versions="17.2 17.1 17.0", release_date="07-24-2024"} 3 delivery_release_patch_status{versions="17.2 17.1 17.0", release_date="08-07-2024"} 1	delivery_release_patch_status{versions="17.2 17.1 17.0", release_date="08-07-2024"} 1	delivery_release_patch_status{versions="17.2 17.1 17.0", release_date="07-24-2024"} 3

Content

• Query for patch status with both versions and release_date
  • Fix for edge case on publish day where updater fetches the incorrect status from the metric for an already-published set of versions-release_date