WI: Phase A: Use the revision API in more places

Added an item to the summary for release manager signoff, because this has an impact on the technical debt and releasability of 8.2.x. For example, there are a number of existing bugs and limitations with revisions that become more problematic when we use revisions in more places. I'd like to see an overview of those bugs here, and consider what we need to fix in order to consider the work on revisioning releasable.

For some of my concerns, see #2490136-101: Enable revisions by default. For example, #1239558: Deleting an entity with revisions and file/image field does not release file usage of non-default revisions, causing files to linger could be a scalability problem already with just nodes being revisionable by default. Some of the issues we added on the main roadmap #2721129: Workflow Initiative under "Related work" might also belong here.

Also clarified why product manager signoff is important and added that for release managers too.

Adding another related issue.

And another one.

I think we should split the revision hash/parenting issue out to a separate issue, since they only block phase H.

And/or if they block something earlier could that be clarified?

Adding #2745619: [policy, no patch] Which core entities get revisions? since it is related and needs discussion. Also see @effulgentsia's feedback at #2705389: Selected content entities should extend EditorialContentEntityBase or RevisionableContentEntityBase.

Here's an update on the status of this plan from the committers!

Release manager
A release manager needs to sign off because the scope and impact of the work are significant for core, and because existing issues with revisions may impact the stability and technical debt of the developmental minor version.

To address this, the framework managers, release managers, and Entity Field API maintainers did a triage of revisioning issues with the Workflow team last week, with these results:
https://docs.google.com/spreadsheets/d/14lpbLhpu7YqjFwjQ4gCTTlf-gcrOc57C...

For each issue, we identified which must, should, could, and won't block or be a part of this phase of the initiative. We can update the summary here for that info, but this has release management signoff based on the planned scope of work and those related issues being included.

Previously @catch and I had concerns about the impact of enabling revisioning for many entity types in core without a way to manage the revisions, but this phase is not about that. It is simply about providing the API and storage. The revisioning flag will not be set for core entity types other than nodes during this phase, nor possible to enable through the UI.

Product manager
A product manager needs to sign-off on this plan because the revisioning user experience is not as polished as the non-revisioned user experience, so the planned work significantly affects the out-of-the-box experience of the product.

These were the things that needed product manager signoff for this phase:

1. User experience changes out of the box as a result of #2490136: Enable revisions by default -- most issues were already addressed in the original issue, or are covered by the "must" revisioning work in the spreadsheet above. One outstanding issue affecting the product usability was #1776796: Provide a better UX for creating, editing & managing draft revisions., and @webchick commented there agreeing that one can be a "should" or even "could" for this phase.
2. Proposed revisioning UIs for other entity types -- no longer in scope.

Based on that, @webchick said it was okay to remove the "Needs product manager review" tag here as well.

Finally:

Framework manager
A framework manager needs to sign-off on this plan as the above phases introduces a small, but very significant, API addition (parent revisions).

The framework managers were comfortable with phase A overall, pending reviewing the implementations of the remaining steps of course. However, they were less sure about phase B. Based on that, we thought it might be worthwhile to split Phase B into a separate issue.

Adding the other must, should, and could revisioning issues to the summary.

Removing the "won't" issues from the related issues.

Clarifying WRT the signoffs in the summary.

Three moreissues related to revision support/forward revisions:

#2856363: Path alias changes for draft revisions immediately leak into live site

#2861506: Add support for changing taxonomy term parents in pending revisions

#2858434: Menu changes from node form leak into live site when creating draft revision

And #2858431: Book storage and UI is not revision aware, changes to drafts leak into live site.

Most things here have been completed. There's only one must-have issue that is not yet completed I think: #1239558: Deleting an entity with revisions and file/image field does not release file usage of non-default revisions, causing files to linger. But that issue dates back to at least 2011, and AFAICT doesn't need to block progress on the relatively smaller B phase?

Time to start #2786133: WI: Phase B: Extend the revision API with support for parents?

@Wim Leers, yes, that issue is one of the tasks that we'll focus on for 8.7 :)

You mean, #2786133? 🙏 😃

Yup, that's the one.

Wonderful! 🎉

@amateescu: We're working on revision support in JSON API in #2992833: Add a version negotiation to revisionable resource types. We just discovered that (Node|Media)RevisionAccessCheck seem to be sort of "on their own": it appears there's no standardized Entity API infrastructure for dealing with revision access. Is that correct? Any input you would have on that subject would be super welcome. See #2992833-150: Add a version negotiation to revisionable resource types. Thanks! 🙏

#3043321: Use generic access API for node and media revision UI is the issue that will tackle the inconsistency regarding revision access APIs mentioned in #42.

#1239558: Deleting an entity with revisions and file/image field does not release file usage of non-default revisions, causing files to linger is no longer a must-have for the Workflow Initiative (per comment #130 in that issue), and I just closed #2745619: [policy, no patch] Which core entities get revisions?, so I think we call this done as well!

🥳