Release confirmation: Releases made when RC is disabled don't show up upon enabling

[dd32]

When a plugin has release confirmations are enabled, we store some metadata about each release that is made.

This metadata is specific to release confirmations, and is not related to the 'previous versions' metadata.

When RC is first enabled the list of releases is first requested, we pull in all previously-known releases into the history metadata.

When a new release is made while RC is active, we add it to that metadata.
If RC is not enabled, we don't add metadata.

Some plugins have enabled RC, and then had it deactivated, and later have re-enabled it. When this happens, the metadata ends up being out-of-sync, as we haven't stored any releases into the data while it was disabled, and because there was previous data, we haven't filled it generated data.

For example:

1. Release 1.0, 1.1, and 1.2
2. Enable RC. Metadata has 1.0-1.2.
3. Release 1.3, and 1.4.
4. Disable RC. Metadata has 1.0~1.4
5. Release 1.5, and 1.6.
6. Re-enable Release Confirmation. Metadata still only has 1.0~1.4.
7. Release 1.7. Metadata now has 1.0~1.4 + 1.7

This causes some plugin authors to be concerned at step 6, as they're afraid that they won't get confirmation notices for the upcoming 1.7 release.

This also causes some data issues as now they don't have the 1.5+1.6 releases showing up in their release history.

Ideally, we should either:

• Always add releases made by plugins to metadata, regardless of RC. (my personal preference)
• If RC metadata is present but not enabled, add metadata upon new known releases anyway.
• Discard data upon it being disabled, or, when re-enabled fill in any releases made while it was deactivated.

This is slightly complicated by releases from trunk, which RC does not support, so the metadata may be incomplete for those "releases". (See also, #6380)

[dd32]

In 13874:

Plugin Directory: Always add the release metadata for plugin releases from tags.

See #7696.

[dd32]

After reviewing this, the original ticket is incorrect.

Having release confirmation enabled was not a prerequisite for it, as it turns out, the releases metadata has been filled for a bunch of plugins that did not have it active. The cause of this is due to Plugin_Directory::get_releases() not needing release confirmation active in the first place.

As a result, I'm decoupling the releases data from release confirmation, and refreshing those plugins data.

[dd32]

In 13876:

Plugin Directory: Store plugin releases from trunk as trunk@1.2.3, split the releases prefilling into it's own method.

See #7696.

[dd32]

In 13877:

Plugin Directory: Release confirmation: Revert accidental variable rename included in [13876].

See #7696.

[dd32]

In 13935:

Plugin Directory: Release Confirmations: Check to see if a release required confirmation before importing it.

When a plugin first enables release confirmation, there won't be any confirmation metadata for a release, as it didn't require confirmation.
Release Confirmations should only apply for future releaess, not existing releaess, so we should allow modifications to the existing versions.

See ​https://wordpress.slack.com/archives/C1LBM36LC/p1722304228950529
See #7696.