Automatically provide a changed field definition

Here we go.

That's true. Reverted the order to how it was previously. I updated the description to include the entity type. It's now pretty much identical to how it was before except for 'edited' vs. 'changed', which I changed (no pun intended) because the latter is actually more correct.

I slightly expanded the scope of this issue to rename $entity_type to $entity_type_id in baseFieldDefinitions(). It seemed wrong to introduce this incorrectly as $entity_type in changedFieldDefinitions(), and I also didn't want to introduce a further inconsistency. I can revert that, if people are worried about kitten safety.

Right I definitely want to wait on the changed issue, but I wanted to post this to get some feedback if people agree with this in principle first.

Will re-roll.

Here's a re-roll.

Hmm... not sure. I'm not so keen on entity keys in general, but it sort of does seem it would be consistent here.

Anyway, here's a re-roll, which should pass. And this implements #10 for now. Thoughts?

Well, that was not particularly smart... :-)

Oh lord, this is so embarassing...

This needed a re-roll after the changed field type.

Here we go.

Oh, forgot to mention this: I changed the implementation to not return an array of field definitions but return the single field definition directly. This made for a more fluent API when setting additional stuff on the field definition (i.e. isRevisionable() or isTranslatable()) like CustomBlock or Node do. This can be seen in the patch context.

So #2506213: Update content entity changed timestamp on UI save already "fixed" this, however in a problematic way, because it hardcoded the name of the changed field to 'changed'. However, maybe after #2635224: ContentEntityBase should provide field definitions for key fields we can use this to auto-generate the changed field and fix the hardcoding.

Let's see.

Hmm.. should apply to 8.3.x, though, so re-uploading.

The interdiff in #40 is incorrect, but the patch itself looks good, it fixes the media and workspace entity types to no longer declare the changed entity type.

Will pick this up and attempt to fix #29, i.e. remove the "automatic" adding of the entity key. I'm fine with having to add this explicitly, but I think we should then do that for all core entity types and provide respective update paths to add them.

I think we can also still provide the field in ContentEntityBase and I think we should then update EntityChangedTrait to fall back on 'changed' as the field name, but with a deprecation notice, so that in Drupal 10 a 'changed' entity key will be required for using EntityChangedTrait. Of course, feedback on all parts of this plan is much appreciated.

OK, here's an updated patch that should be fair bit along the path laid out in #43. In detail the following patch:

• Adds a default description to the changed field. This is taken from what most of the fields are currently using. I didn't (re-)introduce the descriptions for minor textual differences in the description (in particular "that the" vs. "the") but I did (re-)add an overridden description for files as the difference between "editing" and "changing" seemed noteworthy there, as files are not actually ever edited in Drupal.
• Removes the default changed key per #29
• Updates EntityChangedTrait to fall back to hardcoding changed as the field name (with deprecation). There is not yet deprecation testing for this.
• Added an override to SqlContentEntityStorageSchema to not mark the changed entity key as NOT NULL in the schema. This is also mentioned in #29 already.
• Adds a changed key to all core entity types with an according update function (except for the test entity types). UpdatePathTestBaseFilledTest passes with this applied, so this seems to work. Not sure if we need dedicated update path tests for this because any outstanding schema changes would already fail all existing update tests. I think not, but not sure.
• Adds checking for the changed key to ContentTranslationHandler and ContentTranslationMetadataWrapper. I found this by just checking where 'changed' is referenced in core. The fallback to hardcoding changed is still there with deprecation. The deprecation testing for this is also still missing.

Sorry, not yet in the habit of running the pre-commit script locally. This one should be better.