The stored field schema does not contain field-level primary keys, unique keys and indexes

Here we go. Extracted this from #2928906: The field schema incorrectly stores serial fields as int. Interdiff is relative to #4 over there and should hopefully fix the tests. Could be that I messed something up in the split though...

Looked at the test failures, but similarly to #2928906: The field schema incorrectly stores serial fields as int this requires #2938951: The primary key is not correctly re-created when updating the storage definition of an identifier field because we are updating the field storage definitions as part of the update, so we need to recreate the primary keys.

OK, so here's a re-roll on top of #33 from #2938951: The primary key is not correctly re-created when updating the storage definition of an identifier field.

Once we get a green here, we can start tackling those todos from that issue that point here to prove that they are warranted.

+++ b/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorageSchema.php
@@ -1384,8 +1369,8 @@ protected function createSharedTableSchema(FieldStorageDefinitionInterface $stor
+              if (!empty($schema[$table_name]['primary key']) && in_array($name, $entity_schema[$table_name]['primary key'], TRUE)) {

Ahh borked the re-roll here. This should be $schema in both cases, and we should remove $entity_schema altogether here. Should in theory not affect green-ness, though. We'll see...

This fixes #9 and one other thing I borked up in the re-roll + bumps the update functions to 8.6

index 0000000000..5a86d59e2c
--- /dev/null

--- /dev/null
+++ b/2929120-2.patch

index 0000000000..740c90403a
--- /dev/null

--- /dev/null
+++ b/test.php

Sorry, that's stupid. Will leave that out of the next one.

This should fix at least some of the fails.

Of course, I ran into #2928906: The field schema incorrectly stores serial fields as int here. Adding more duct-tape for now in order to keep those separate.

D'uh, wrong extension. Here you go, little bot.

OK, more duct tape for #2928906: The field schema incorrectly stores serial fields as int

So this revealed a bug, yay ;-): When we change the serial field to an int during an update of a field definition we never actually change it back. So we should do that. ...except not for user entities of course, as those do not use serial field at all. Hah, this is so much fun... ;-)

Unless I broke anything else - which is entirely possible - this should be green. Will then attempt to remove some of the hacks introduced by #2938951: The primary key is not correctly re-created when updating the storage definition of an identifier field.

Let's see.

Now testing my theory that the ugly workaround in SqlContentEntityStorageSchema::processBaseTable() is only needed due to this.

Here's a re-roll. This still contains some cruft which can be removed, but let's see if this is green first.

So the problem was that when we were merging field schemas, we were passing a schema array with multiple indexes to addIndex(), but only with the fields that are needed for one of them. So we need to make sure that only a single index is part of the $index_schema array.

Hope this will be green, will try to remove the primary key stuff if so, as I'm pretty sure that it's no longer needed.

Maybe this time?

OK, this time with less cruft. The interdiff does not show the (re-)removal of (the previously introduced here) AssertSchemaTrait as that is no longer needed because I accidentally removed it with PhpStorm 😡. But the patch should be significantly smaller now.

Alright, this now covers all existing entity types. I guess we want to add a change record, but in terms of the patch this should be RTBC-able/reviewable now, at least from my perspective.