Let orchestra_api and orchestra_client run without the Orchestra engine, moving server-only code to orchestra_server_api and the request limits and remote pages under Web services

Problem/Motivation

A site that only needs to talk to a remote Orchestra had to install the whole engine. For example, a site that hosts the forms a workflow on another site collects. orchestra_client depended on orchestra_api, and orchestra_api depended on orchestra.

Almost nothing in the client stack used the engine. A few places tied it to the engine, and some code that only the answering side uses lived in the module both sides install:

• LocalOrchestraClient, the engine's in-process client, lived in orchestra_api and was the reason it depended on orchestra. Its only consumer is the orchestra_server_api ApiController.
• AcceptedIdentitySchemes and IdentitySchemeResolverInterface, which decide the identity schemes this site accepts from a caller, also lived in orchestra_api, though only the answering side uses them.
• NoticeController in orchestra_client counts requests with Drupal\orchestra\FloodGuard, which read its switch and its period from orchestra.settings. Its route, /orchestra-notice/{orchestra_remote}, accepts a POST from anyone, because only the signature over the body authenticates the sending site, so a client site needs FloodGuard as much as the engine site does.
• The pages of orchestra_client sat under the engine's /admin/orchestra section and required the engine's administer orchestra permission.

This is the first step towards starting and resuming workflows from a webform on another site. That other site installs only orchestra_api, orchestra_client and a small webform module. The rule is that nothing a client site installs is specific to the answering side, and a site with the engine, the server API and the client together keeps working.

Proposed resolution

• Move LocalOrchestraClient, its service and the binding of OrchestraClientInterface to it from orchestra_api to orchestra_server_api. orchestra_client still wins that binding on a site that also answers the API, and ClientBindingTest now checks it against orchestra_server_api.
• Move AcceptedIdentitySchemes and IdentitySchemeResolverInterface to orchestra_server_api.
• Move FloodGuard to orchestra_api, with its switch and its period in a new orchestra_api.settings config. The Request limits section of the Orchestra settings form becomes its own page, Configuration > Web services > Orchestra request limits. orchestra_interaction, whose capability links it counts, now depends on orchestra_api.
• Give orchestra_client its own permission and move its pages to Configuration > Web services: Remote Orchestras and Orchestra notices.
• Remove orchestra:orchestra from the dependencies of orchestra_api. The kernel tests of orchestra_client leave the engine out, and ClientSiteWithoutEngineTest installs the client the way a site does, checks that the engine stays out, and checks that every new page names a permission the site defines.

Orchestra is pre-beta, so the classes, services and config move with no deprecation layer and no update hook.

Remaining tasks

• Review.
• On each site with orchestra_interaction, run drush en orchestra_api before drush cr, switch request limits on again at the new page if they were on, remove the old keys with drush config:delete orchestra.settings flood, and grant the new permissions.
• Follow-up in yoyaku and pdv: their kernel tests that enable orchestra_interaction must enable orchestra_api too.

User interface changes

• The Request limits settings move from the Orchestra settings page to Configuration > Web services > Orchestra request limits.
• The Remote Orchestras and Notices pages move from the Orchestra section to Configuration > Web services, the second one renamed Orchestra notices.

API changes

• Drupal\orchestra_api\LocalOrchestraClient becomes Drupal\orchestra_server_api\LocalOrchestraClient, and the binding of OrchestraClientInterface to it moves to orchestra_server_api. An engine site with neither the server API nor the client no longer binds the contract.
• Drupal\orchestra_api\AcceptedIdentitySchemes and Drupal\orchestra_api\IdentitySchemeResolverInterface move to Drupal\orchestra_server_api. The service becomes orchestra_server_api.accepted_identity_schemes, and resolvers are tagged orchestra_server_api.identity_scheme_resolver.
• Drupal\orchestra\FloodGuard becomes Drupal\orchestra_api\FloodGuard, and the service orchestra.flood_guard becomes orchestra_api.flood_guard.
• New permissions: administer orchestra request limits and administer orchestra remotes. The remote pages no longer accept administer orchestra.

Data model changes

The flood keys move from orchestra.settings to orchestra_api.settings.

AI-Generated: Yes (Claude Code was used to help draft this issue summary and to write the change and its tests. I reviewed them, and the new tests were confirmed to fail when the engine dependency is put back, when a page names a permission no module defines, and when the request limits form saves the wrong key.)