Add a `langcode` data type to config schema

Added suggestion for one more place

🥳 Posted a first review, but this is looking excellent already!

I just have a single request for clarification … other than that, this is IMHO RTBC already! 🤩

Definitely missing a change record to announce this new config schema type though! 🤓

Tweaked the change record to be more similar to the one for #2920678: Add config validation for the allowed characters of machine names.

Tightened test coverage in 2 ways (which were the sole remaining concerns I raised in my review). This required adding a single additional line to the config schema definition.

IMHO this is now RTBC 😊

This new data type for config schemas is a good addition to make configuration schema's more strict. I had one remark on the pull request but @Wim Leers pointed out that should not be an issue. I'm in the hopes that the last pull request will pass tests so already setting this to rtbc.

There's 31 test fails with the MR 🤔

Mea culpa — forgot a single period! 🙈

This time I waited for the testbot to come back green. Back to RTBC.

This blocks #2443991: Allow default_langcode field value to be changed, which is marked Major. Matching priority.

Setting to NW based on a few items I added to the MR. What I'm asking about is likely pretty trivial so if that proves to be the case, whoever addresses this can switch it back to RTBC without waiting for another NR cycle.

An additional question: are there contrib/custom cases that might result in errors on update? It seems possible since this constraint is applied to the langcode: property of the root configuration object. It gets a "The value you selected is not a valid choice." error, but perhaps at least the CR could include a section on how to most easily address the error if a site encounters it? Ideally it's phrased in a search-engine friendly way for those who don't read change records but get the error.

Applied the MR to 11.x
Searched for "label: 'Language code' and all the instances appear to have been captured.
CR makes sense to me.

Think this is good.

+1 I reviewed that this took into account the custom langcode configuration languages.

Asked some questions on the merge request

I'd use reset() instead of key(), but that's too nitpicky for not RTBCing this. All feedback so far has been considered already.

Do we need release notes for this? I don't think so.
Change record? Exists at https://www.drupal.org/node/3373721.

So IMHO RTBC

+1 on the rtbc.

Bad news: Back to NW because of a test failure
Good news: looks like the failure might be because this validation works/

Back to rtbc now that the test coverage looks complete.

Love to see schemas get smarter and more leveraging of those handy Symfony validation constraints. Committed to 11.x