New association methods break workspace cleanup

Problem/Motivation

#3494770: Simplify getAssociatedRevisions() and getAssociatedInitialRevisions() from core added a custom implementation for WseWorkspaceAssociation::getAssociatedRevisions() and ::getAssociatedInitialRevisions() which is supposedly improved based on how this module is architected. Fair enough.

But \Drupal\workspaces\WorkspaceManager::purgeDeletedWorkspacesBatch() expects to only receive one revision ID per entity ID and now it receives multiple. This causes the following loop to attempt to delete an entity with its revisions multiple times, leading to "TypeError: get_class(): Argument #1 ($object) must be of type object, null given"

      foreach (array_keys($associated_revisions) as $revision_id) {
        if ($count > $batch_size) {
          continue 2;
        }

        // If the workspace is tracking the entity's default revision (i.e. the
        // entity was created inside that workspace), we need to delete the
        // whole entity after all of its pending revisions are gone.
        if (isset($initial_revision_ids[$revision_id])) {
          $associated_entity_storage->delete([$associated_entity_storage->load($initial_revision_ids[$revision_id])]);
        }
        else {
          // Delete the associated entity revision.
          $associated_entity_storage->deleteRevision($revision_id);
        }
        $count++;
      }

With the original implementation, this would never have happened as that implementation properly joins the base table with the revision table, leading to only one revision ID per entity ID.

Steps to reproduce

• Using the latest version of WSE, try triggering a purge of deleted workspaces. This could be done through a cleanup in a DTT test or any other common means.
• Alternatively, compare the potential output of the original methods to WSE's and notice that there are differences. This due to the fact that WSE's implementation uses the revision table directly (by calling allRevisions() on the entity query).

Proposed resolution

• Either undo this optimization or fix it so the output matches the expected output of the parent.
• Or, argue that the interface wasn't clear on this and ask core to change WorkspaceManager to be more defensive about the associated IDs (not likely going to happen but worth a try)

Remaining tasks

Fix

User interface changes

N/A

API changes

N/A

Data model changes

N/A