[PP-2] Add parallel revisioning support

Problem/Motivation

At the moment core only supports sequential revisioning, however there are any many use cases that would be far better addressed if we had parallel revisioning support in core. The typical example is an entity going through a set of significant changes (either via Workspaces or via an editorial workflow implemented via Content Moderation) and at the same time needing a small typo fix in its default revision.

On top of that, we have no way to make it easy for multiple modules exploiting parallel revisioning to play well together, which means incompatibilities may arise between core and contrib or even in core itself, given that at the moment Workspaces and Content Moderation would not be able to interact with each other.

Supporting parallel revisioning would require us to implement some kind of conflict detection/resolution to be able to merge changes from different revision branches into the default revision.

Proposed resolution

The following proposed solution was originally discussed by @amateescu and @plach and posted at #2942907-24: Entity system does not provide an API for retrieving an entity variant that is safe for editing. Additional information about the thought process behind the proposed solution is available at #2942907-26: Entity system does not provide an API for retrieving an entity variant that is safe for editing. In general all comments between #27 and #34 are somehow relevant to this issue and should be taken into account while working to the final solution.

Use cases

To validate the design it was chosen to use primarily a fairly advanced, although strictly-real life, use case: editing, in the context of a "stage" workspace, a translated and moderated entity, whose edit form has an hypothetical autosave functionality relying on revisions enabled.

Each entity translation goes through an independent editorial workflow. Once all translations reach an approved state, the workspace is ready for deployment to live. While editing the entity, autosave would trigger the creation of revisions that are only visible to their owner, the active user.

Other use cases we took into consideration, assuming the scenario described above, were:

• the display of a multiple inline entity form widget on the entity form;
• the display of the core Revision UI.

Implementation plan

Exploit the API introduced in #2942907: Entity system does not provide an API for retrieving an entity variant that is safe for editing to provide a way to retrieve the most suitable entity object to populate an entity form and to be displayed with respect to the current context. The specified contexts provide all the required information to perform the revision negotiation.

In the reference scenario above they would be:

• current workspace
• active language
• current user

As mentioned in #5, multiple implementers need to collectively participate in the revision selection process without having to hardcode assumptions about each other. To achieve that, revisions are organized in a hierarchy representing how the implementers handle individual revisions. Each revision has a reference to its parent along with additional metadata about the context the revision was created in.

Each implementer is defined via a "revision type" plugin, which may be tied to one (or more?) context. The definition includes a weight that is used to build a hierarchy between context items, for instance: workspace → active language → user.

The revision graph (a tree allowing two parents for each node, technically a directed acyclic graph) represents the revision branches that may be generated when editing an entity in multiple contexts. In the reference scenario above, an entity might be edited in multiple workspaces, in multiple languages, by multiple users each one triggering their own autosave revisions.

This graph structure is also used for conflict resolution: when needing to merge revision branches a new merged revision having two parents will be created.

As mentioned above, each revision has contextual metadata attached, allowing to look up the fittest revision for the specified context. In fact a revision matching exactly the specified context might not exist, so a fallback logic needs to be available. The context hierarchy defined through weights is used to support that: more and more generic fallback contexts are built until a suitable revision is found. For instance the following situation may happen:

 Current context:  [ws: stage, lang: it, user: 4]
 Fittest revision: [ws: stage, lang: it]

Assigning a sensible weight to each definition is likely to imply some degree of mutual knowledge among revision types, however theoretically this should not require explicitly coding against each other. It should even be possible to alter definitions to change weights and thus the way revision types play with each other.

OTOH altering revision type definitions and changing context info might make some revision contexts invalid, in which case the fallback logic would have to kick in again with possibly unexpected results.

In the reference scenario above, we have three context-defining revision types: Workspace, Content Translation, Autosave. Content Moderation does not require any special kind of context, so it does not need to affect the revision lookup logic. On the contrary, adopting this new API should allow us to simplify/clean-up the current limitations around revision translation and possibly deprecate the revision_translation_affected flag and the logic around it, as mentioned in #2940575-24: Document the scope and purpose of pending revisions.

While the public API mentions variants, since it's dealing with both revisions and translations, under the hood the revision graph will be used to identify the revision most suitable for the specified context and then the entity translation matching it will be instantiated and returned.

Remaining tasks

• Introduce a custom implementation of the tree field to implement the revision_parent field with the parent revision reference(s) and the context metadata (parent issue).
• Basic implementation of the public API.
• Implementation the solution based on the revision graph (this issue).
• Introduce multiple support for editable revisions (follow-up issue).
• Add displayable support, both individual and multiple (follow-up issue).

User interface changes

None

API changes

None expected

Data model changes

None expected

Release notes snippet

TBD