Views exposed sort identifiers are not configurable when also exposed

This:

- needs tests
- need upgrade path tests.
- needs updating provided views in all profiles (and recipes?).

Otherwise might be ready. Marking Needs review for getting feedback before working in tests.

I think the feature makes sense and is probably much harder to do in contrib than adding it to core since this stuff isn't exposed in any sort of hook.

I'm not sold on the names and descriptions used here. I'd use 'key' and not 'id' to describe these, but even than it's still pretty hard to grasp what these are for. Since this is some pretty specialised config, we need strong descriptions to make clear what these are for I feel.

Thanks @lendude seems like solid feedback.

@lendude Given this manifested as an error message, I was tempted to mark this even as a bug instead of Feature request.

Naming these are hard. In the meantime I used suffix as you suggested.
The descriptions definitely need work.

This now contains tests, including for the views upgrade.

Looks super close. Left 2 more comments on the MR.

Fixed config schema validation.

Thanks feedback appears to be addressed

Feature makes sense and coed looks great.

It seems that there are a couple of scenarios that should be taken into account during validation, though:

• expose_sort_key & sort_order_key needs to be unique, as it happens with exposed form identifiers.
• Collisions with exposed form identifiers need to be avoided as well

Otherwise, the exposed form merges the 2 different form elements into a single one, having unexpected results and validation errors when loading the form.

In the screenshot below, the Content view was modified, setting the same value for both expose_sort_key & sort_order_key. Only one of the dropdowns is rendered, and failing validation.

Something similar happens if any of the exposed filters identifiers is used for any of the new options (langcode or type for the Content view).

Might be necessary to extend DisplayPluginBase::isIdentifierUnique() to cover this scenario and pull it up to PluginBase