Incorporating foundation of "Notes" feature

[t-hamano]

• Related Gutenberg Issue: Graduate Block Level Commenting from Experiments gutenberg#71826
• Related Gutenberg PR: Notes: Graduate from experiments gutenberg#72344

This PR updates the core codebase to allow the Notes feature to work properly.

Trac ticket: https://core.trac.wordpress.org/ticket/64096

Note

This PR also includes #9869. Don't forget to add the following prop when committing to core:

Props ristojovanovic, adamsilverstein, jeffpaul.

[t-hamano]

Ok, I believe backporting PHP should be all done. Next, I'll try to fix the failing tests.

[Mamaduka]

Ok, I believe backporting PHP should be all done. Next, I'll try to fix the failing tests.

I think we're missing the Notes-specific unit tests.

[Mamaduka]

There's another PR for get_pending_comments_num changes - #9869.

Just noting for props.

[swissspidy]

Not a fan of hardcoding comment types. Long term we should think about using a filterable list of comment types to exclude or using (an improved) WP_Comment_Query

[Mamaduka]

100%. I think a long-term solution is to provide proper support for custom comment types, so we can avoid hardcoded patches like we've introduced with the current implementation.

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• The Plugin and Theme Directories cannot be accessed within Playground.
• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

[jeffpaul]

@desrosj any idea why the Playground bot commented after the PR was closed versus after it was opened? Seems like it ideally triggers after a PR is opened so folks have an easy way to test, yeah?

[desrosj]

@jeffpaul The workflow that leaves the Playground comment runs when the Test Build Process workflow completes (the results of the build process are zipped and uploaded to these runs).

Looking at the timeline of events on the PR, I think what happened was as follows:

• 2ad2332 was merged into the HEAD branch.
• ~10 minutes later, the commit to trunk was made and mirrored to this repository in c62fe7e.
• The Test Build Process workflow was probably still running at this time, or had not started and was queued because of the log jam that happened leading up to beta 1.
• The workflow finally finished and triggered the commenting workflow ~30 minutes later.

The commenting workflow does not currently check if the PR has been closed before posting. It just relies on the prerequisite workflow run completing. There is Core-61568 on Trac that is aimed at only sharing a Playground link when the changes are being made would actually be testable within a Playground instance. For example, GitHub Action workflow files cannot be tested in Playground. I am going to add this to a comment on that ticket so it does not get lost.

[desrosj]

Despite being reported several times and continually deleting the content, this account continues to spam this PR. I am going to lock the conversation for this PR to avoid the massive amounts of noise until GH takes action on the account.