[Policy] Deprecate Action (UI) module in D10 and move to contrib in D11

Tagging for product manager review.

The actual core actions are provided by system module. Action module just provides a (very confusing and clunky) UI for creating 'advanced actions'.

I was concerned that VBO might need action module (since VBO could be an eventual core candidate for more admin UI-building), but it doesn't require it at all, so moving actions out is no barrier to moving VBO in.

So to me it makes sense to move out the 'advanced actions' UI and while leaving the API and existing actions in core.

Update title

Removing a thing from core requires signoff from all the committer roles, as well as an opportunity for the subsystem maintainer to provide feedback if there is one. (There is none here.)

The committer team recently reviewed our scoring exercise on all core modules. There is a reasonably strong consensus that Action is neither a foundational capability nor strategically valuable to the product roadmap, so it should be moved to contrib. I am marking RTBC, but leaving the tags on to give committers a chance to confirm that they agree.

Deleted the wrong tag.

Myself, @catch, @quietone, and @longwave all agree on moving Action to contrib.

I'm happy moving this if we're talking about 'Action UI' module i.e. keeping the system parts of action APIs that drive things like bulk actions at admin/content for example.

Just to confirm #8, the actual actions are provided by system module and are available whether this module is installed or not, this is just the UI for creating 'advanced actions'.

Thanks @catch for clarifying this. So the ActionPluginManager will stay in core even if the Action UI module moved to contrib, right? That would be ideal from our ECA module point of view, because that's what we rely on. And core is our sole dependency, we would certainly want to keep that if possible.

Clarifying the title. I agree the Action UI module included in core is very basic and does not really allow the capabilities of actions to shine. (Just look at ECA!!) Indeed its used rarely, not maintained and does not have a contrib ecosystem that extends this UI in particular. Signing off as one of the core product managers.

@jurgenhaas: https://api.drupal.org/api/drupal/core%21core.services.yml/service/plugi... is the service I think you mean? It is in core.services already not in the UI module :)

@jurgenhaas in terms of ECA module, there's related issues
- #2011038: Use Context system for actions
- #2083649: Rename action module to action_ui

Thanks @Gábor and @andypost this is much clearer now. And yes, the context system is on our radar for ECA.

Do we need a child issue for the actual deprecation patch?
Do we want a "action system" in the Drupal project issue queue? Right now it's really easy to classify something accidentally as "action.module" instead of "system.module"

It needs new meta for that, as there's separate issue to decouple test groups