Triggering deprecations for migrate plugins using annotations and plugin types not supporting attributes

It looks like the current plan is to deprecate the Drupal 6/7 source plugins in 📌 Deprecate migrate source plugins Postponed , this will probably result in a lot of the same tests being marked legacy, so we can possibly postpone this on that issue once @legacy is added to tests there?

Another option would be to re-convert

migrate_drupal

migrate source plugins to attributes and set the source_module property for them all in a hook_migrate_source_info_alter implementation in migrate_drupal. Effort probably would not be that high because all the plugin class changes could be brought back from an earlier commit, so it would just be purging the source_module property from them and writing the giant alter hook.

I think I like #3 because it's forward compatible. If someone is going to need migrate_drupal in D13, this needs to be done anyway.

migrate_drupal is going to be deprecated with no replacement for removal in Drupal 12 rather than moved to contrib. This is on the basis that sites can migrate to Drupal 11 which will be supported until 2028, years after Drupal 6 and 7 went EOL. This doesn't preclude someone extracting the code from Drupal 11 to a contrib module anyway but it won't be done as part of the deprecation process.

Noted, then I think we either wait on the tests to all be marked as deprecated in 📌 Deprecate migrate source plugins Postponed or for D12 when it's gone.

This is just for runtime deprecations in tests. Doesn't stop anyone from writing a general purpose phpstan/upgrade_status detection for classes in plugin namespaces with annotations and no attributes that would also work on migrate plugins.