Allow replacement ZIP upload for new submissions

[dd32]

Currently the plugin review queue accepts a single ZIP upload, which is then used for review.
Iterations of the plugin are then emailed to the plugins team directly.

There are two different stages of plugins where we deal with ZIPs:

1. New, unreviewed
2. Pending, being reviewed

In the first case, we should just allow the plugin author to upload an additional ZIP, so the reviewer has it when they pick up the plugin. This is more of an issue now that the review queue is >1 week, there's a higher chance that the plugin has been iterated on while it's waiting to be reviewed. Authors often contact us asking "how do we send it?", and often also send time-limited or login-required links.

In the second case, almost all plugins need iterations before being approved, the ad-hoc nature of emailing ZIPs means that our automated tools can't easily be run over the files without manual work. It also bypasses the super-basic checks included in the current upload submission process.

In other words - To simplify the review process for all, we should allow additional ZIP to be uploaded for plugins (prior to approval).

[dd32]

Pending plugins:

When a plugin is in the pending state, the plugin reviewers still need to be notified somehow about the fact a new fixed ZIP has been provided.

There's two real options here:

1. Rely upon the plugin author to respond to the review email letting us know they've uploaded the new version
2. Attempt to automate it, re-open the helpscout ticket with a note stating that a new ZIP has been uploaded.

I'm thinking that we really need to do both; the reason is several fold:

• We're humans, and it's a manual review process, we don't want someone feeling like it's 100% automated and that they can fix an issue, submit a new version, get told they still haven't fixed everything, goto:start.
• Our WordPress <=> HelpScout integration isn't perfect, it's not always immediately apparent which email is the review email for a given plugin (Due to several factors, both technical and human). If we automate this and we re-open/add-a-note to the wrong email there's a high chance that the reviewer may not be aware of the new ZIP
• Sometimes authors don't actually fix all the issues highlighted in reviews, intentionally, as they may feel that something raised isn't actually something they need to fix - Sometimes it's not, and they simply need to tell us why it's not relevant to the plugin.. if we automate it, and the author doesn't let us know that they intentionally didn't fix item 3, the review enters yet another review stage.

So.. I think it needs to be both: Attempt to re-open/note the ticket, but also ask the author to respond to the review email noting which issues they've fixed and if they have any questions/concerns raised by the team.

Draft PR for review purposes.

[dd32]

In 13109:

Plugin Directory: Allow plugins to upload additional versions for review.

This is currently limited to new plugins, which is prior to the first human review.

Iterations upon this will open it to plugins in the pending state as well, which is during the human review.

See #7384.

[dd32]

In 13110:

Plugin Directory: Fix a fatal in the blueprint generator when multiple ZIPs exist.

See #7384.

[dd32]

In 13112:

Plugin Directory: Remove unused Review_Tools::save_post().

See #7384.

[dd32]

In 13113:

Plugin Directory: Submission: All uploaded zips now have this metadata attached, simplify the code added in [13109].

See #7384.

[dd32]

In 13114:

Plugin Directory: HelpScout Client: Fix the client to work with POST requests, which require specific content-type handling.

See #7384.

[dd32]

In 13115:

Plugin Directory: Submission: When a pending plugin has a new ZIP uploaded, instruct the author to email the team, but also re-open the ticket with a note about the new upload.

See #7384.

[dd32]

In 13116:

Plugin Directory: Submission: When a pending plugins review email can be found, and it's showing as active, update the user-facing text to indicate it's waiting on the review team NOT the author.

This might reduce some confusion when an author see's it's waiting on them, and expected the text to be dynamic.

See #7384.

[dd32]

In 13117:

Plugin Directory: Review Tools: Allow the reviewer to upload a new .zip to the plugin post.

Props davidperez for the report.
See #7384.

[dd32]

In 13127:

Plugin Directory: Add a new post-plugin-submission email, which references new features and reiterates expectations of the author.

This introduces two new email classes, to provide HTML emails, and Markdown emails.
A markdown email is converted into a HTML email, but makes it easier to write the template.

Note: This email is not yet active.

See #6943, #7384.

[dd32]

In 13132:

Plugin Directory: Use the new post-plugin-submission email template.

See #7384.
Fixes #6943.

[dd32]

In 13198:

Plugin Directory: Allow plugins in review to upload additional ZIP archives.

This allows plugins to upload a ZIP while waiting for their initial review, and once that review takes place, to upload additional ZIPs for review.

See #7384.

[dd32]

In 13210:

Plugin Directory: Allow pending plugins to have a slug when updated by a non-reviewer.

In [13198] we've allowed pending plugins to upload new ZIPs for review, but this triggers a wp_update_post() which clears the post_name field for users who can't publish a plugin.
This overrides that and prevents the slug overwrite.

See #7384.

[dd32]

In 13212:

Plugin Directory: Upload: List the uploaded plugins with the most recent first, move the upload-additional prompt to the start of the list to match.

See #7384.

[dd32]

In 13307:

Plugin Directory: Admin: Add a Submitted Date column for simpler sorting of pending plugins.

The only other field is the 'Last Modified' date field, which increases when a new ZIP is uploaded to a draft/pending plugin.

See #7384

[dd32]

In 13308:

Plugin Directory: Upload: Don't overwrite the post_date field when uploading a new version of the plugin.

This will allow for more performant queries for pending plugins.

See #7384