New translations for moderated nodes are not created in the initial workflow state

Problem/Motivation

We have defined a workflow with these states:

1. Draft
2. Needs Review
3. Published

We have two roles:

• author (Who creates content in draft and sets it to "needs review")
• admin (Who can transition from "needs review" to "published")

Steps to reproduce

1. Enable the Content moderation and Content translations modules, and their requirements.
2. Add another language to the site.
3. Enable translation for Content (nodes) for at least one content type.
4. Enable the Editorial workflow for at least one translatable content type.
5. Configure the workflow with the 3 states listed above (draft, needs review, published), and 4 transitions:
   1. draft -> draft
   2. draft -> needs review
   3. needs review -> draft
   4. needs review -> published
6. Configure 2 roles:
   • author (with permission to use draft -> draft and draft -> needs review transitions)
   • editor (with permission to use all of the above workflow transitions)
7. An author has created a node in English, and sets it to "needs review".
8. Now the author wants to add a translation for this node. They go to the Translate tab and click on the "Add" Button.
9. The form where they can edit the node and add the german texts is displayed.
10. When they click "Save", they gets the error message "Invalid state transition from Needs review to Needs review".

Logically that is correct, because the author role doesn't have the permission to edit nodes which are in the state "needs review".

But shouldn't new translations be treated as new nodes and therefore be created as "draft"?

Proposed resolution

Preserve the existing behavior for BC, but add a way to configure this when defining a workflow.

Whatever new UI is introduced should only be visible if both Content moderation and Content translation modules are enabled.

Option B

(Other rejected proposals removed, this is what we're going with).

• Have a simple toggle for the current behavior vs using the default moderation state (same as A)
• UI is 2 radios.
• Setting stores a string, ID would be 'translation_default_moderation_state_behavior' or so, with values like 'current' vs. 'default'.
• In some UIs, explicit radios for different options can be more clear than a checkbox (if each choice requires a little explanation).

Example UI:

Initial moderation state when adding a new translation:
(*) Default moderation state
( ) Current moderation state of the original content

Open questions

1. Which UI is best for the setting? Option B - radio buttons. See #45
2. Since all the code handles no value for this setting as if you want the current behavior, do we need an upgrade path and all that complication? Yes (@larowlan in #42)
3. Do we want to add this setting to the default workflows shipped with core? YES
   1. core/profiles/standard/config/optional/workflows.workflow.editorial.yml? YES
   2. If so, should we set it to 'default' or 'current'? Using 'current' per @larowlan in #42
   3. Also demo_umami? YES
4. Does this issue need a CR? YES: https://www.drupal.org/node/3240957
5. Do we need more test coverage? YES:
   1. Do we need to test the UI for this setting when configuring a workflow? YES (per @larowlan in #44). DONE in patch #47
   2. A kernel test covering the scenario in the issue summary YES (per @larowlan in #42). DONE in patch #47
6. Should the #default_value for these radios use 'default' for new workflows? It's now defaulting to 'current' if missing from the config for BC on existing sites. But presumably we could notice when creating a new workflow and use a different #default_value to be the more intuitive 'default'. NO, leave it as 'current' (per @larowlan in #42).
7. Where is the right layer of the entity / translation / content_moderation systems to specify the default moderation state of a new translation? See comment #33. We don't want to have to rely on field widgets to enforce this setting. It'd be better if we directly changed the moderation_state when populating a new translation so that field widgets don't need to support this setting, and so it works if there is no widget for moderation_state. Should we?
   1. Use hook_entity_translation_create() YES.
   2. Directly hack EntityOperations::updateOrCreateFromEntity()? This seems problematic since we'll have a hard time knowing if the entity has a value from a widget or if its own override logic should kick-in. NO
   3. Other?
8. What should the UI help text say for the "Legacy" config option? See #101.

Remaining tasks

• Answer the open questions.
• Implement the new setting / UI.
• Don't check if the user has access to this transition (because it should be treated as new).
• Add a DB update for existing sites
• Add tests:
  1. What you see when creating a new translation (the bug)
  2. The two different roles case described in the summary. Done in #47
  3. The upgrade path
  4. The UI for this when creating a workflow. Done in #47.
• Decide what to do that the legacy behavior is not "Current moderation state of the original content" as the UI suggests, but actually a hardcoded choice between exactly 'published' (if the original content is currently in any published state) or 'draft' (for any unpublished current state). See #91 UX team proposed a solution in #101, implemented in #104
• RTBC

User interface changes

A new setting when creating/editing a workflow:

Before

What you see without the patch applied, or when content_moderation is enabled but content_translation is not, at paths like /admin/config/workflow/workflows/manage/editorial:

After

With the patch applied, and both content_moderation and content_translation enabled:

Initial moderation state when translating existing content*
(*) Default moderation state
( ) Published if existing content is published, otherwise Draft

API changes

None.

Data model changes

New config schema for a setting on workflow type plugins.

Release notes snippet

TBD.