Provide setting to allow stubs to create stubs

Yeah, I understand. I've ran into circular stubbing issues myself (when I was still using core's MigrateStub).
And I think it's more of an issue with the migration itself, and it should have logic in place (e.g. through the migrate_conditions module) to stop it from stubbing itself e.g. Ensure that you do a no_stub look up initially so if it's already been stubbed, that ID is used, rather than attempting to stub itself.

process:
  # Get the current node ID.
  # And later use that in a custom process to skip the row if it's a stub or something.
  my_nid:
    -
      plugin: migration_lookup
      migration: self_referential_migration
      no_stub: true
      source: node_id
    -
      plugin: skip_on_empty
      method: process
    -
      plugin: default_value
      default_value:
        - null
    -
      plugin: extract
      index:
        - 0
      default: null

But yeah, I understand the concern either way (and everyone's migration is different, mine however requires entity stubs to be able to create stubs just so the second migration creates the entity I want to reference).

Do you have a concept or idea how to prevent circular stubbing when somebody uses the feature you proposed?

We'd keep a list of currently currently stubbed entities using a key like: "$migration_id:$source_id", and use that avoid potential duplicates if it finds that the same entity is already being stubbed.

The default behaviour is to limit it to at most 1 entity stub at a time (current behaviour), then configurations which require 'stub entity -> stub entity' behaviour can do so by updating their settings.php to either 0 (no limit), or increase the limit to 10 or whatever maximum they forsee themselves using if they're worried about circular stubs.

I've created a Draft MR with my implementation - still needs test, but we probably need to fix the existing failing tests first, so we can confirm that it doesn't break anything.

edit: On further thoughts, think its better to be set for each individual migmag_lookup process, rather than a global setting (as I wanted that stub -> stub behaviour on a specific process).

process:
  target_id:
    plugin: migmag_lookup
    migration: d7_node_complete
    source: nid
    # We'd skip the limit check if the process in question allows stubs to create stubs.
    no_stub_limit: true # Or stub_stubs: true?
    stub_default_values:
      langcode: 'source_property',
      field_foo: '@destination_property'

The MR also includes the edge case Exception handling logic raised in #3571993: MigMagMigrateStub::$mainStubProcessHasStarted can be stuck as TRUE if the stub throws an exception downstream

Upon further reflection and understanding the code a bit more, I updated the MR with a per-process configuration instead.

It's more scalable as the behaviour I wanted was for a specific lookup, rather than globally.