Move content_entity source plugin to migrate module

I added a draft change record so that the deprecation messages can refer to it: https://www.drupal.org/node/3498916

There is a kernel test. We can just move that, right? Or do we need to lave behind a wrapper class and deprecate it?

I moved four classes: the source plugin, its deriver, and two test classes. Maybe that is enough for this issue.

I updated the phpstan baseline file. Maybe, as part of this issue, I should fix those errors and remove the entries from the baseline, instead of updating those entries. I might also add return-type declarations and use constructor promotion ... or maybe that is scope creep.

Let's see what the testbot thinks.

The CR was unpublished because I got confused by the base field and the regular boolean field, both of which (if you have access to them) are labeled "Published". I think you should be able to see it, now.

I suppose we do not have to make the old class a wrapper for the new one. We could just add the deprecation notice (in the class docblock and in the constructor) and remove the plugin annotations. Then we could add return-type declarations in the new class and it would have no effect on any code that extends the old class.

@nicxvan:

I did the following:

1. Restore the classes in the migrate_drupal module (but keep the deprecation notices).
2. Revert the changes to the phpstan baseline file.
3. In the new classes (in the migrate module), fix the errors from the phpstan baseline file.

Was I right to restore the test class in the migrate_drupal module? Maybe I should delete it again, along with the corresponding lines in the phpstan baseline file. I did not restore the test that refers to the source plugin by its plugin ID instead of by its class: that no longer tests the deprecated class in the migrate_drupal module.

Since we are giving up on keeping the new classes as close as possible to the old ones, I made some further modernization:

• Add parameter and return-type declarations.
• Use constructor promotion.

I had some trouble with phpstan. It is tricky when tests implement methods without declaring return types, for example.

If the tests pass, then I will move this issue back to NR.

I resolved the new "unused parameter" error after discussing on Slack with @nicxvan and @mstrlan.

@mondrake, thanks for the comments on the MR. I replied to all three, even though I only made the changes suggested in one of them. I am adding credit to you for the review.

I updated the Proposed resolution in the issue summary: we decided not to make the old classes wrappers for the new ones (because we are adding type declarations that could break BC).

I still wonder whether I should remove core/modules/migrate_drupal/tests/src/Kernel/Plugin/migrate/source/ContentEntityConstructorTest.php, which tests the now-deprecated class. The MR copies that test class to core/modules/migrate/tests/src/Kernel/Plugin/source/ContentEntityConstructorTest.php.

Failing tests:

1. Drupal\Tests\jsonapi\Functional\JsonApiFunctionalTest
2. Drupal\Tests\file\Functional\DownloadTest
3. Drupal\Tests\package_manager\Build\PackageInstallTest
4. Drupal\Tests\package_manager\Build\PackageInstallSubmoduleTest
5. Drupal\Tests\package_manager\Build\PackageUpdateTest
6. tabbingManagerTest.js (I think: certainly one of the Nightwatch tests)

I am re-running the tests, and I will add a comment to #2829040: [meta] Known intermittent, random, and environment-specific test failures.

There were merge conflicts in the PHPStan baseline file.

I rebased on the 11.x branch, skipping the commits that affected the baseline file. I also used the opportunity to simplify the git history. Then I manually removed the lines from the baseline for the removed test class and added an ignored error for the new version of that file with

phpstan analyze -c core/phpstan.neon.dist -b core/.phpstan-baseline.php

Back to NR to make sure I did not mess it up with my rebase. It looks as though PHPStan has already approved of the changes.