Deprecate Seven theme

This would be a minor-only change (and, obviously, is blocked on Claro being stable). Since 8.9.x and 9.0.x are now in beta, I'm moving this to 9.1.x. Thanks!

This probably needs product manager sign-off, I think that's been done implicitly, but maybe not explicitly in a 'deprecate Seven' issue.

Decide whether we should automatically upgrade sites using Seven to use Claro in the following major release

I don't think we should do this personally. If we move Seven to contrib, then it's viable for sites to keep using it if they had a specific reason to, and an update would actively prevent that. It would also probably have to be done in 9.x - if you get to the Drupal 10 update with seven installed and it not in core, you're in trouble before the update can even run. And switching theme on people in a minor release seems unnecessary.

Sites can manually switch to using Claro now. Marking Seven as lifecycle: deprecated will inform them what's going to happen.

Let's see what happens.

Postponing on #3278124: Convert various tests that use bartik/seven to olivero/claro.

Updating the issue and parent according to the developing policy on deprecating modules and themes.

Removing the postponed because the task "a section on Deprecated and obsolete themes and themes" can be worked on as well as adding a change record.

I am definitely fine with deprecating Seven. I also don't think we should automatically update people to Claro in 9.x but we either need very solid docs or maybe some automation only in 10.x to cover the special case of Seven theme not existing to switch to Claro then? That way people can add the Seven theme to their build and keep using it or ignore the docs and magically get Claro? I think that would be a 10.x only feature though and I would not hold up deprecating Seven on it for sure. (Also I don't think that is a requirement but since we expect most sites to go that route, some kind of automation on 10.x only would be useful).

+1 to what Gabor proposes

but we either need very solid docs or maybe some automation only in 10.x to cover the special case of Seven theme not existing to switch to Claro then? That way people can add the Seven theme to their build and keep using it or ignore the docs and magically get Claro?

This is going to be very difficult for a couple of reasons:

1. Themes have to be present in the filesystem in order to be uninstalled. We can't allow a theme to be 'missing'.

2. block_theme_initialize(), which maps enabled blocks between regions when a new theme is marked default, generally does not do a good job and requires manual intervention. So if we switch a site to Claro, it could end up with blocks in funny places, and short of a hard-coded mapping of common block and region combinations, not sure what we could do. This is coming up in #2635166: block_theme_initialize() falls back to putting blocks in the first region it finds, provide a better default for test coverage.

A solution to #1 would be to provide a stub seven.info.yml with lifecycle:obsolete. We would have to check that Seven is installed, but that it is the obsolete version, and only switch to Claro if both are the case. And this might have to happen in a pre-update step (i.e. when you load update.php) since updates are carried out in the admin theme.

But while that potentially might help with #1, it doesn't do anything for #2.

For documentation, we could definitely customize an error message and prevent updates altogether if the admin theme is missing, pointing people to documentation.

Triggered some retests to see what's left to do here.

Let's see if this fixes the tests.

Added a change record.

1. Reviewed the patch. All looks good and clear to me. Passing on 9.5.x.
2. Reviewed the CR. Needed a very tiny edit. Otherwise simple and great.
3. Reviewed https://www.drupal.org/node/3223395#s-seven (the lifecycle link). All looks good.

Nothing else to complain about. No pending signoffs or blockers. RTBC! Thanks

Agreed on re-RTBC. Here's the interdiff to confirm #28. Thanks!

Technically I worked on the patch here, but there's no logic change so I think I'm still OK to commit this given the multiple +1s.

Committed/pushed to 10.1.x, cherry-picked to 10.0.x and 9.5.x, thanks!