Contact message "uid" field has target_type "contact_form"

If the schema has already been broken, do we need to migrate any data? It never would have worked to begin with?

MR up with a straight uninstall + reinstall update hook.

Was that an accident @andypost?

No, for reason of tests

There was 1 error:
1) Drupal\Tests\contact_storage\Functional\ContactStorageTest::testContactStorage
Behat\Mink\Exception\ElementNotFoundException: Form field with id|name|label|value "field_storage[subform][settings][allowed_values]" not found.
/builds/issue/contact_storage-3158051/vendor/behat/mink/src/WebAssert.php:731
/builds/issue/contact_storage-3158051/web/core/tests/Drupal/Tests/UiHelperTrait.php:85
/builds/issue/contact_storage-3158051/web/core/modules/field_ui/tests/src/Traits/FieldUiTestTrait.php:105
/builds/issue/contact_storage-3158051/tests/src/Functional/ContactStorageTest.php:218
/builds/issue/contact_storage-3158051/vendor/phpunit/phpunit/src/Framework/TestResult.php:729
ERRORS!
Tests: 8, Assertions: 229, Errors: 1.

@andypost thats only in gitlab CI, which is also failing on HEAD. I was trying to get some quick fixes through but obviously it needs more work so I will split that stuff into a separate issue.

🐛 t() calls should be avoided in classes RTBC contains the t() fixes.

> If the schema has already been broken, do we need to migrate any data? It never would have worked to begin with?

But it has worked, the field has a default value callback, so it is storing data. It just happens to be storing the user ids as strings. There are aspects that wouldn't work, like doing a join on that field on PostgreSQL, but storing would work there too.

Unsure what to do about this, for most sites that field won't matter, but there absolutely might be use cases that rely on the uid and this will delete their data.

Rebased for 8.x-1.4, only conflict was the use statements in contact_storage.install