Disallow saving the current default revision as a non-default revision

Created a merge request, this should fail.

Fixed a few bugs in the tests, now there's a sensible amount of fails.

don't really understand what Drupal.KernelTests.Core.Entity.RevisionableContentEntityBaseTest is doing, but I don't think what it does is sensible.

\Drupal\KernelTests\Core\Entity\EntityDuplicateTest::testDuplicateNonDefaultRevision() is #3220784: ContentEntityBase::createDuplicate() should reset default revision flag, forgot about that, that was RTBC but then somehow it got lost once it was set to needs work. Probably a blocker for this.

\Drupal\Tests\content_moderation\Kernel\ContentModerationSyncingTest::testUpdatingPreviousRevisionDuringSync() is tricky, it's resaving an old revision that was default but no longer is. I'll need to double check if we have a way to detect the difference between current default revision and previous default revision. The migrate tests might be similar, not sure yet.

\Drupal\Tests\menu_ui\Functional\MenuUiContentModerationTest::testMenuUiWithPendingRevisions is the fail I expected. I have one idea that we can try, but it will complicate things a bit and it depends on content_moderation specifically. The idea is that we'd create that menu link to the latest route, where access is denied if you don't have access to preview the draft, and change it back. But it complicates things, we always need to look for that route, or at least if it's a non-default-revision node being edited and update the target on publish.

This stuff really has rabbit holes inside rabbit holes.

The migrate EntityRevision destination plugin calls setDefaultRevision(FALSE) since 2014, i honestly don't know why. It loads an existing revision or the default revision, neither should have a reason to change whether or not it's currently a default revision, it should just update that revision. Lets see if removing that breaks any tests.

For the menu_ui stuff, the changes that only partially worked inside #3485030: Avoid saving menu links through node form when they do not change actually passed then here. The reason for that is again the partial and incorrect fix that was done in #2850022: Duplicating a non-default revision should produce a default revision for a newly created entity , which allowed the partial and incorrect implementation in #3041326: Remove 'title' and 'description' from MenuSettingsConstraintValidator when used with content moderation by creating a draft of menu link content when a draft of it's parent content is created. What we did is accept the changed value for isDefaultRevision() but then the return value ignored the current value and returned always TRUE if the entity is *currently* new. That means that it correctly saves the change as the default revision but then in post save, in \Drupal\menu_link_content\Entity\MenuLinkContent::postSave(), it now sees that it's actually supposed to be not a default revision, so it doesn't update the menu tree storage. Meaning, the menu link content entity exists as a regular enabled default revision, but it's just not in the menu tree. Saving it through any other means than the node form on a draft would then however resave it properly and it would become visible.

What I did there now is as suggested above, point those menu links to the /latest page, then they show up but only for users who are allowed to see the latest version. It's either that or not allowing to create new menu links on a draft. And I changed isDefaultRevision() to ignore a new value on a new entity, so that it doesn't change in the middle of saving.

I also removed the first check about new and not default revision, because both old and new implementation of isDefautRevision() do not allow for that to happen.

I see lots of new fails though, so I'll need to investigate where that comes from.

This should come back green now and is ready for feedback/reviews. Comes with extensive explanations on the MR about the changes. Could likely do with some adjusted inline comments, open for suggestions.

The threads are mostly just explanations on the changes because several of them were very complex to figure out and resolve. I'm not sure how extensive the inline comments should be. I'm both looking for general reviews and feedback and suggestions on if and how code documentation should be extended/adjusted.

To manually reproduce problems with this, try these scenarios, always make sure that content moderation is enabled.

A)
1. Create a new published node with a menu link, name both Foo (or whatever, just as an example to reference later).
2. Create a draft of this node, also change the menu link title to Foo Draft. Note how the visible menu title doesn't change, like you'd expect as it's just a draft.
3. Check the menu_link_content_data and menu_link_content_field_revision tables. note how you actually only have one revision and no draft like for the node, and the data table has Foo while the field_revision table has Foo Draft.
4. Edit the menu, note how the title in the overview is Foo (persisted value in the menu tree table, but editing shows Foo Draft (the value you get from loading the menu_link_content entity. Save that menu link.
5. Note how it's now consistently Foo Draft.

B)
1. Create a new published node Bar, no menu link.
2. Create a draft of that node, add a menu link, name both Bar Draft.
3. No menu link shows up, kind of as expected. Nothing in the menu either.
4. Check the tables again, note how the entity actually exists as the default revision with Bar Draft.

c)
Mostly same as A, but with translations, for example on umami. Things get even weirder then, sometimes it's Foo, sometimes Foo Draft, also for anonymous users, so it's very much not a draft. This is because on multlingual sites, \Drupal\menu_link_content\Plugin\Menu\MenuLinkContent actually loads the menu_link_content entities and displays the title for the current language.

All these things happen due to the combination of problems, outlined in #7. For a new entity, new revision on HEAD is forced to TRUE, but it can switch in postSave(), which results in the menu link not being saved into the menu_tree table. For existing entities, it results in only updated the revision tables, resulting in inconsistent data (loading loads from revision tables, but for example entity query would then find the old value only, and you can't revert to the old revision).

With the changes here, things will be more consistent, although not perfect I'd assume. For B, you should see a menu link then, to the latest page, but only as a user with access to that page. For existing menu links, saving a draft should actually save it as a draft and never show, translations or not. However, I'd expect the menu edit experience might be strange, haven't actually tested that yet. menu_link_content entities don't actually support content_moderation, you can't officially manage drafts there, so you might see the default revision then on edit and saving that might result in losing access to the draft. The node edit form should consistently show the draft though and on publish make it the default revision. I think improving menu edit should be it's own issue, should maybe actually disallow edit in that scenario as there's no UI to really deal with that situation.

Addressed the reviews.

See #3511768: Avoid incorrect and unecessary menu_link_content entity saving

I created change record, but there's really not much to say except "don't do that". If you hit that with existing code you will need to carefully review the code and the data you're working with and change something. I want to stress again that doing this was silently breaking your data, now we disallow that. There were essentially only two affected cases in core, both pretty arcane, the menu link stuff which was doing highly illegal things and migrate, which is doing some really creative things with retroactively creating "old" revisions.