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.

[dd32]

In 13959:

Plugin Directory: Release Confirmation: Remove releases for deleted tags earlier.

When a SVN tag is removed the relevant release is deleted [13711], but that only applied when release confirmation was enabled.

As of the changes in #7696 releases now exist even if release confiramtion isn't enabled, as such as should always remove any release meta for any non-explicitely-confirmed releases.

This also has the effect of resolving an edge-case where the deleted tag is present within trunk/readme.txt as the Stable Tag but the release was discarded/not-confirmed, in that case $stable_tag would be set to the fallback value of 'trunk' for the SVN import and ultimately release confirmation would reject the import (as trunk is not currently valid for that scenario).
That would cause the release NOT to be deleted, although the tag was. Replacing the tag with the corrected data would not re-trigger the confirmation process if the release was previously discarded.

See #7696, #5900.