[Brain dump] UB From Dataless Schema, Projection Workflow Duplication, and Proposed Solution

# Potential problem

This issue will list some potential problems the current API does not handle.

## UB from incorrect event payload schema in storage

- A swarm protocol is identified by its name, an arbitrary string.
- A swarm protocol contains information on its events.
- The schema of the event payload is TypeScript-type only. It can only be parsed when a TypeScript compiler SDK is available.
- A swarm protocol's events are identified by 2 tags: "[swarm_name]" and "[swarm_name]:[arbitrary_id]"
- 2 swarm protocols with the same name can "run" on a single Actyx instance.
- Consequently:
- A machine runner can accidentally subscribe to events from a different version of the swarm with the same name. This can cause the state machine in the machine runner to come to an unintended conclusion.
- Event's data-less schema, combined with subscribing to the wrong swarm protocol version can cause the machine runner a runtime crash.

## Specific-role projection is not well-formed.

- In order to define a correct swarm-protocol and its machine-protocols, these protocols have to be written separately and then cross-examined using machine-check.
- These definitions are separately written, but all definitions represent a subset of the same imaginary state machine, the one written as the SwarmProtocol itself.
- Furthermore, the well-formedness of the machine protocols is checked individually. It is possible to instead check the well-formedness of the swarm protocol and then derive the machine protocols from it.

# Proposed Solution

The first problem is solvable by caveats, versioning how-tos and best practices, and examples.

The second problem is negligible depending on how the developer can afford to sacrifice writability for the sake of easily solving the distributed-state-machine problem.

However, here is an alternative API:

## The 3 steps compilation

1. Swarm Protocol Design:
Events and swarm state machine (state label and transitions) are defined here. Event payload schema is dataful and uniquely identifiable. Swarm state machine name and the event payload schema will be summed into a unique identifier for the Swarm Protocol. The format of the event tag will roughly be "[swarm_name]:[swarm_identifier]:[arbitrary_id]". The preceding information are compiled into what we will call from this point forward simply: The "swarm protocol". The swarm protocol includes 1.) the swarm name,2.) the events, and 3.) the unique identifier. The swarm protocol will be used for the later steps.
2. Machine Protocol Design:
This step uses a compilation result of the first one, let it be just the "swarm_protocol". This step defines the 1.) roles involved in the swarm protocol and 2.) for each role, relevant states from the swarm protocol are marked, optionally, payloads are assigned to these states, and commands are assigned to each of these states. A command contains 1.) the command name, and 2.) the chain of events that will be emitted. The preceding information, mapped into the corresponding role, are compiled into several "agent protocol", one for each role.
3. State Machine Design:
From "agent protocol", we can deduce the complete list of "reactions" and "commands". The first action in this step is to "extract" "reactions" and "commands" which are written into a set of definitions that are useful to verify the user's code. Optionally, this extraction method can produce a boilerplate code. The user will then be able to write the details of the "reactions" and "commands" on top of the boilerplate code.