Deprecate using Classy as the default theme for the 'testing' profile

Problem/Motivation

In #2350823: Use the Classy theme in the Testing profile we "temporarily" changed the testing profile to use classy theme (instead of stark) as we cleaned the CSS classes out of core and into classes.

Meanwhile, there are a number of issues that are trying to fix bugs in core's markup, many for various form elements.

Drupal 8 frontend backwards compatibility (BC) policy says we can't change templates for stable or classy until D9.

Comments like #2443815-111: #description_display broken for details elements seem to regularly paralyze attempts to fix legitimate bugs, since no one understands what to do once the "stable and classy should remain intact" comment is posted.

How are we actually supposed to fix the bugs in core? The 'testing' profile uses the classy theme. So if we try to fix a bug, we're supposed to update the tests, but if we can't fix the classy templates, the tests will never pass. Deadlock ensues.

Sample of bugs that have come to a halt as a result of this policy:

• #2396145: Option #description_display for form element fieldset is not changing anything
• #2419131: #states attribute does not work on #type datetime
• #2443815: #description_display broken for details elements
• #2945727: Form radios/checkboxes elements should have js-form-wrapper class
• #2982187: datetime-wrapper.html.twig ignores #description_display parameter
• #2988461: Radios template does not apply form-radios class
• ...

Proposed resolution

Ensure that our test suite runs against a theme with base theme: false so that our tests actually test the core module templates and CSS, not a theme that our BC policy prevents us from fixing.

In particular, return the testing profile to stark and update all the tests as necessary to compensate for the new, stripped down markup.

Drupal 8.8.x release will be the last release for adding new deprecations (for Drupal 9). Therefore, we should try to get at least the code that deprecates this behavior into Drupal 8.8.x. This would essentially allow us to continue working on this in Drupal 8.9.x.

We introduce a new optional $theme property for choosing default theme for tests extending Drupal\Tests\BrowserTestBase and use the testing install profile. The optionality of that property is deprecated and will be made required in Drupal 9. This is similar to what we are doing for the theme info.ymlbase theme property in #3065545: Deprecate base theme fallback to Stable.

This change would allow test cases to pick between Classy, Stable and Stark. If Classy gets deprecated in Drupal 9, test authors would have a way to convert their tests to a theme which support will continue.

Explicit vs implicit

Our BC policy allows tests to break between majors. At the moment, most tests use classy, because that is the default theme in the testing install profile. During the Drupal 9 cycle, classy is going to be deprecated to be removed from Drupal 10. Probably in Drupal 9.1 or 9.2.

If we can avoid new tests from being written against classy before it gets deprecated, then we can also avoid them needing to be rewritten during the Drupal 9 cycle.

This is why it’s very valuable to nudge Drupal developers towards explicitly specifying the theme they’re going to be testing against while using the testing install profile. They can still choose to stick to defaults during the Drupal 8 cycle (that’d be classy), but if they do explicitly specify the theme to be used, their tests will not need to change for a long time to come.

Future default value? Would it be opt-in or opt-out?

Today, the default theme when writing tests is classy, which is going away in the future.
The patches so far in this issue are indicating that there will be no default. But “no default” is just one of the possible choices. There are 3 possible choices — see #68, or preferably, see #3081131: Decide default theme for testing, which is the dedicated follow-up issue for determining what the future default should be, and whether it should be opt-in or opt-out.

Remaining tasks

1. THIS ISSUEThis issue only introduces the deprecation, and skips it. Why only this scope? To ensure this lands in time before 8.8.0. Only this portion of the patch is truly essential to land before 8.8's alpha deadline.
2. FOLLOW-UP#3082655: [PP-1] Follow-up for #2352949: specify the $theme property in all functional tests then unskips the deprecation error and makes all core tests compliant. This already results in most tests being converted from classy to stark. But it does so without changing a single assertion. Why only this scope? Because it keeps it easier to review and allows even a novice user to do this work.
3. FOLLOW-UP After that, #3083275: [PP-2] Follow-up for #2352949 and #3082655: update tests whose assertions are implicitly relying on Classy markup to not rely on it anymore takes a critical look at the tests that the previous step added protected $theme = 'classy'; to. Every test that has that yet is not explicitly testing Classy markup should have its assertions updated, so that it can switch to stark (or perhaps stable).

API changes

None.

User interface changes

None.

Data model changes

None.