[META] Remove deprecated modules on the Drupal 9 branch

I think this issue is duplicate of #1255674: [meta] Make core maintainable

I don't see it as a duplicate at all. That issue, as currently written, proposes to remove features from core. Whereas the items in this issue's current summary aren't about removing features.

There's an issue to have the simpletest UI generate a string to run phpunit tests from the command line. If that feature existed, it's one thing we might want to keep from simpletest module. #2566767: Don't allow running phpunit-based tests via the UI

There needs to be a UI in Drupal to run tests, whether that's in Simpletest or something else it doesn't matter so long as one exists. Right now Simpletest cannot be removed because a replacement isn't available.

Ah, found it: #2312191: Change Simpletest UI from a test runner to a CLI snippet generator

Regarding the hook stuff in the IS... See https://www.drupal.org/node/2881531

Clarifying title. They would be removed before the Drupal 9 release but not in Drupal 8 :) Also re-parenting to the right issue.

The overall task of this issue is a must for Drupal 9. Therefore raising to critical. The concrete list of them is not agreed on.

The language is a bit unclear what the proposed resolution is.

In #13 @Gábor Hojtsy said

The concrete list of them is not agreed on.

Should we have a separate issue for the most contentious items? For instance, action ➡️ action_ui should not be blocked on toolbar/settings_tray.

I also want to propose to deprecate the HAL module in D8.8 so we can move it into contrib in D9. I have a very basic proposal in #3049856: [policy] Mark HAL module as deprecated in D9 so it can be removed in D10. Maybe we can get some eyes on it.

For completeness, some more coremodules considered to be moved into main Core: #2202925: Move simple field types into Core/Field

Added migrate multilingual issue.

I am obviously out of the loop but please can we have some explanations here as to why these changes are being made? I'm not averse to making changes but I am not happy about changes "just because".

Could we have a principle here that a separate issue is created for each proposed change, and then linked back here, which gives space for questions about particular modules to be addressed outside of this issue, keeping the conversation clean. This also gives space for the necessary explanation of how to work around the removal for sites that currently use that functionality.

@rivimey: there will be no modules removed in this issue, this is a Plan/META issue to help track the list of issues. Each module will definitely have its own issue. For modules that are already deprecated at least there will be an issue to remove them against the Drupal 9.0.x. branch (once it is open). For modules that are not even deprecated yet, there will also be an issue against 8.y.x to deprecate it first.

Hey Gábor, thanks for that update. It is good to know.

I admit I'm getting a little nervous about all this deprecating, considering the promise that D9 will be an easy upgrade. I'm with you all on things that have been deprecated for many versions (e.g. since 8.2.x) but deprecating in 8.8 for removal in 9 seems to me a step too far - I hope this is not happening.

Added #2083649, #3007167 and criteria to the IS.

Removed #2966859 because it was postponed until D9.

Work happening here: #3057420: [meta] How to deprecate Simpletest with minimal disruption

Reparenting to beta1 requirements since Drupal 9 is open for development.

#2083649: Rename action module to action_ui is not actually deprecated yet, removing it from the issue summary.

- settings_tray/toolbar - settings_tray is in core as stable, so again nothing is deprecated. Also removing this.

Block -> block_ui has not happened at all, removing this too.

We could open another meta for module mergers and renames, but this should only deal with actually-deprecated and/or experimental modules that are never going to be stable.

Updated the issue references for simpletest and entity_reference to the current ones.

This has been done to the extent that it can be, all individual modules have their own tracking isses.

Remove related issues that were re-parented to Drupal 10.

And one more.