We moved all the source plugins into their relevant modules within core but now they all have a hidden dependency on migrate_drupal because the source classes extend DrupalSqlBase. This is exposed when you use the migrate source plugin manager to discover the plugins but then get a fatal error when instantiating a plugin because of the missing DrupalSqlBase class.
- Add an annotated class discovery variant which automatically discovers provider dependencies based on namespace (of its class and every class it extends). Which is different from core that just looks at the namespace of the class and not its parents.
- Use this in the new MigrationSourcePluginManager.
- Move the provider filter logic from findDefinitions into a decorator and while at it, expand it into multiple provider support.
- Add a migrate specific decorator which removes plugins which try to use non-existing source plugins. Since we automatically discover the migrate_drupal provider dependency of the source plugins as they extend the DrupalSqlBase class this fixes the original issue.. almost.
- Add the provider list to the few migrations which are not automatically covered because they use a source from migrate: empty and embedded_data. Currently, there are only three, all three using embedded_data. Now we are really done with the original issue.
- While it could be called a different issue, we are also fixing when a non-migrate_drupal source uses a migrate_drupal deriver by using the new ProviderFilterDecorator -- in fact, this is the reason it exists: DerivativeDiscoveryDecorator::getDeriverClass() will get cranky and throw an exception if you try to call a nonexisting deriver. Could be a follow up but since it's already done, why not. Process plugins are definitely a followup because they need the definition normalizer to happen on discovery instead of runtime. Destination plugins could be here but they are an easy followup as they are rarely a problem.
Add tests, doxygen.
User interface changes
Data model changes