SPIKE: Exploring the WP state change machine to create custom transitions

[PriyaBhatia0210]

Breaking up the technical research required for our Workflows solution into following constituent pieces:

In this issue, we'd like to explore what does the WP state change machine entail for creation of custom transitions.

Requirements

1. The ability to create custom transitions between states created in Research: Exploring the WP state change machine to create custom statuses #46
2. The ability to properly design/specify what each transition does eg: Only the author can take a published post to a 'Back to Draft' state to make changes or a 'Under review' state should not be allowed to publish
3. The ability to specify user permissions for certain transitions eg: Only the author or their superior or admin has the permissions to 'Archive' a post
4. The ability to block certain transitions eg: An archived post cannot be taken to a draft state directly. It needs to be unarchived first.

Timebox: 1 day

[PriyaBhatia0210]

Proposed tactic:
(courtesy @rmccue)

Step 1 of this would be to model the state machine using something like XState which can produce a machine-readable version of the state machine in e.g. SCXML.

We can then build atop that and rebuild the state transitions on top of that by unhooking large parts of core and rehooking them in based on the state machine.

Changing the state machine would then be a fairly logical and consistent process, because all transitions would then go via the state machine rather than being hacked around everywhere in core.

This is a decent amount of work, but the largest part by far is breaking down core and rebuilding it. I actually think there's a decent chance we could do this in core itself if it were designed well. If we don't do that, it'll be brittle and require maintenance in every release, plus verification of changes.