8.7.x: update anything needed now that taxonomy terms are revisionable

Thanks @dww!

As far as I know, JSON:API currently hardcodes that only nodes and media are "versionable" resource types, in:
\Drupal\jsonapi\ResourceType\ResourceTypeRepository::isVersionableResourceType

Not sure if or how this was impacted by the change in #3038453: When RevisionableEntityBundleInterface::shouldCreateNewRevision is TRUE, create a new revision on PATCH requests and add an entry in the revision log., though.

Also meny_link_content become revisionable in 8.7.0 #2880152: Convert custom menu links to be revisionable

1. Indeed, there is no Entity Revision Access Control API in Drupal core, so we can't expose Term or MenuLinkContentrevisions just yet. See Workflow Initiative maintainer (and the lead on those two mentioned core issues) @amateescu confirm this in #2992833-151: Add a version negotiation to revisionable resource types.

   You'll see that #2880149: Convert taxonomy terms to be revisionable and #2880152: Convert custom menu links to be revisionable didn't add new access control logic to match that in \Drupal\node\Access\NodeRevisionAccessCheck or \Drupal\media\Access\MediaRevisionAccessCheck, so JSON:API is also unable to add support for either of them.

2. @xjm's remark in #2 about #3038453: When RevisionableEntityBundleInterface::shouldCreateNewRevision is TRUE, create a new revision on PATCH requests and add an entry in the revision log. is also great: if either of those entity types has a bundle config entity type that implements \Drupal\Core\Entity\RevisionableEntityBundleInterface (which is what has that shouldCreateNewRevision() method), then we should look into expand their test coverage.
   But Term's bundle entity type Vocabulary's interface \Drupal\taxonomy\VocabularyInterface doesn't implement this and MenuLinkContent doesn't have a bundle entity type. So, no work to be done there either.

Hence marking this fixed. Crediting all people who contributed to this issue to ensure JSON:API is as complete as it can possibly be, to thank you for your thoughtfulness ❤️ 👏

Yep, no functional changes, but tests are indeed failing. Those will need fixing. https://www.drupal.org/pift-ci-job/1225896

I ported @amateescu's patch at #3015325-49: [ignore] support issue for the core patch to the JSON:API contrib module, which unlike the core patch, also needs to support Drupal 8.5 and 8.6. For now, I only resolved the conflicts to apply to the contrib module's code which also has 8.5 and 8.6 code paths (which resulted in conflicts).

Oh, and I checked all functional changes and can confirm they make sense :)

This will not pass on 8.5 and 8.6, since this patch is making 8.7-specific assumptions.

This fixes the 8.6 and 8.5 failures.

So.. the reason I wrote those fixes as an interdiff to the core patch is because I assume that at least the 8.x-2.x branch of the contrib module won't have to support the 8.7.x core branch after it gets committed, right?

because I assume that at least the 8.x-2.x branch of the contrib module won't have to support the 8.7.x core branch after it gets committed, right?

1. That'd be a correct assumption.
2. But … until JSON:API is committed to core, the JSON:API module should continue to keep be green against Drupal 8.7 HEAD, as it has done ever since the 8.7 branch opened ~6 months ago.
3. And to ease the update path, we need to make sure that any site using JSON:API 2.x today that updates from Drupal 8.6 to Drupal 8.7 without deleting the contrib module still has a fully functioning JSON:API.

So: you're right, but we aim for maximum compatibility and minimal disruption :)

#10 came back green on 8.5 + 8.6 + 8.7. 🚢