Derive path redirect migrations per entity type

👍 This follows exactly the same pattern as #3122649: [PP-2] Derive path alias migrations per entity type (and bundle).

👍 Manually tested, works great!

1. +++ b/src/MigrationPluginAlterer.php
   @@ -0,0 +1,318 @@
   +    // optional migration dependencies of the 'catch-all' url alias migration
   

   🤓 Übernit: s/url/URL/

2. +++ b/src/MigrationPluginAlterer.php
   @@ -0,0 +1,318 @@
   +  protected function getSourceDrupalInstanceVersion(array $migrations) {
   

   👍 Identical to _path_get_source_drupal_instance_version() in #3122649: [PP-2] Derive path alias migrations per entity type (and bundle).

3. +++ b/src/Plugin/migrate/source/d7/PathRedirect.php
   @@ -20,6 +15,8 @@ use Drupal\migrate_drupal\Plugin\migrate\source\DrupalSqlBase;
    class PathRedirect extends DrupalSqlBase {
   

   👍 The changes here are identical to those in #3122649: [PP-2] Derive path alias migrations per entity type (and bundle)'s UrlAlias.

4. +++ b/src/Plugin/migrate/source/d7/PathRedirectDeriver.php
   @@ -0,0 +1,212 @@
   +class PathRedirectDeriver extends DeriverBase implements ContainerDeriverInterface {
   

   👍 This file uses the exact same pattern as #3122649: [PP-2] Derive path alias migrations per entity type (and bundle)'s D7PathAliasDeriver.

While manually testing this in more detail, I encountered some detailed quirks with big consequences:

1. +++ b/migrations/d7_path_redirect.yml
   @@ -24,3 +25,7 @@ process:
   +    - d7_user_role
   

   🤔 Why the dependency on d7_user_role? A dependency on d7_url_alias I could understand, but not this.

2. +++ b/migrations/d7_path_redirect.yml
   @@ -24,3 +25,7 @@ process:
   +    - d7_user
   

   A hard dependency on d7_user can lead to a circular dependency: if the d7_user migration depends on for example a d7_taxonomy_term migration, which in turn contains path aliases and redirects …

   Yes, this is only theoretical.

   But what's worse is that this means that every set of migration plugins that together migrate an entire entity type/bundle will end up depending on the d7_user migration, even if that entity (and its migration) itself does not depend on the User entity type!

   🤓 But … wouldn't a migration_lookup for the uid in d7_path_redirect prevent that problem from occurring at all?

This reroll addresses both remarks.

+++ b/src/Plugin/migrate/source/d7/PathRedirect.php
@@ -78,4 +114,14 @@ class PathRedirect extends DrupalSqlBase {
+  public function count($refresh = FALSE) {
+    if (!$refresh && isset($this->configuration['__count_at_discovery_time'])) {
+      return $this->configuration['__count_at_discovery_time'];
+    }
+    return parent::count($refresh);
+  }

+++ b/src/Plugin/migrate/source/d7/PathRedirectDeriver.php
@@ -0,0 +1,212 @@
+              if (isset($rows) && isset($rows[$bundle_id]) && isset($rows[$bundle_id]->count)) {
+                $this->derivatives[$derivative_id]['source']['__count_at_discovery_time'] = (int) $rows[$bundle_id]->count;
+              }

Now with #3190815: Source count caching broken: impossible to enable source count caching for SqlBase-based source plugins (plus, unneeded cache I/O), a better/simpler approach is possible: let the migration system's built-in source count caching take care of this!

Oops, this is not postponed on that!

Sibling comment to #3122649-41: [PP-2] Derive path alias migrations per entity type (and bundle):

The patches so far generate optional dependencies on d7_shortcut, d7_custom_block, et cetera. This does not make sense, because they only have admin-facing URLs.

OMG d.o you drunk

#3190815: Source count caching broken: impossible to enable source count caching for SqlBase-based source plugins (plus, unneeded cache I/O) landed! 🥳Re-testing.

This is trying to be too clever:

$migration_plugin += ['migration_dependencies' => []];
$migration_plugin['migration_dependencies'] += [
  'required' => [],
  'optional' => [],
];

If any of those keys are set, but null, it fails to create the empty arrays.