[Webform 6.x] Fix subclassing and stop overriding constructors

Replace entity.manager in WebformSubmissionViewController, follow a patch

I think most of these deprecation messages are linked to a few remaining entityManager usages, either as $this->entityManager or $container->get('entity.manager').

Most should be easy to address but some might require additional injections. I could provide a separate patch/issue to address them, but if I need another service injected it might conflict with this. So you could also only do it here.

$ grep -r ">entityManager" .
./src/WebformSubmissionStorage.php:    $field_definitions = $thisMost sh->entityManager->getBaseFieldDefinitions('webform_submission');
./src/WebformSubmissionStorage.php:      $optgroup = (string) $this->entityManager->getDefinition($entity_type)->getCollectionLabel();
./src/WebformSubmissionStorage.php:      $entities = $this->entityManager->getStorage($entity_type)->loadMultiple($entity_ids);
./src/WebformSubmissionStorage.php:      $next_serial = $this->entityManager->getStorage('webform')->getSerial($entity->getWebform());
./src/WebformSubmissionStorage.php:    $query = $this->entityManager->getStorage('webform')->getQuery();
./src/WebformSubmissionStorage.php:      $webforms_to_purge = $this->entityManager->getStorage('webform')->loadMultiple($webforms_to_purge);
./src/Controller/WebformSubmissionViewController.php:    $title = $this->entityManager->getTranslationFromContxt($webform_submission)->label();

$ grep -r "get('entity.manager" .
./src/WebformSubmissionStorage.php:      $container->get('entity.manager'),
./src/WebformOptionsListBuilder.php:      $container->get('entity.manager')->getStorage($entity_type->id()),
./src/WebformSubmissionViewBuilder.php:      $container->get('entity.manager'),
./src/Controller/WebformSubmissionViewController.php:      $container->get('entity.manager'),
./modules/webform_image_select/src/WebformImageSelectImagesListBuilder.php:      $container->get('entity.manager')->getStorage($entity_type->id()),
./modules/webform_access/src/WebformAccessTypeListBuilder.php:      $container->get('entity.manager')->getStorage($entity_type->id()),
./modules/webform_access/src/WebformAccessTypeListBuilder.php:      $container->get('entity.manager')->getStorage('webform_access_group')
./modules/webform_options_custom/src/WebformOptionsCustomListBuilder.php:      $container->get('entity.manager')->getStorage($entity_type->id()),

Nice! Based on a quick glance, the only remaining tests with deprecation messages are integrations tests, so all these are most likely coming from those other modules.

Something with that last reroll patch didn't go as it should have :)

Here's a new reroll, conflicted on:

	both modified:   modules/webform_entity_print/src/Plugin/WebformExporter/WebformEntityPrintWebformExporter.php
	both modified:   modules/webform_group/src/WebformGroupManager.php
	both modified:   src/Controller/WebformPluginElementController.php
	both modified:   src/Form/WebformResultsCustomForm.php
	both modified:   src/Plugin/WebformExporterBase.php
	both modified:   src/Plugin/WebformHandler/RemotePostWebformHandler.php

Mostly use statements, the change in WebformGroupManager is gone as that was already updated from what I saw.

Didn't know about the branch, sorry. Found another small thing as well, One class uses the old path.alias_manager instead of path_alias.manager.

This is on top of your patch in #60, not sure why my complete patch file is smaller.

@jrockowitz: FYI your last patch was empty.

reroll

Yes this is a big patch, and I think those diffs are a bit wrong. Can you please review and commit #3133945: Remove .orig files accidentally committed first, these files seem to be messing with my diff creation (not sure why, just that they are). After those are removed, I'll take another stab at a preroll and include the interdiff.

This is meant to just be a clean reroll. I don't understand why src/Plugin/WebformSourceEntityBase.php is in the interdiff; the file was created when I applied the patch from #73, so I added it here.

Note that I still get warnings when running this on D9. These are Symfony changes that will happen with 9.x. Can we fix those here, or do we need to wait for 9.x release?

[warning] Declaration of Drupal\webform\EventSubscriber\WebformExceptionHtmlSubscriber::on403(Symfony\Component\HttpKernel\Event\GetResponseForExceptionEvent $event) should be compatible with Drupal\Core\EventSubscriber\DefaultExceptionHtmlSubscriber::on403(Symfony\Component\HttpKernel\Event\ExceptionEvent $event) WebformExceptionHtmlSubscriber.php:31
 [warning] Declaration of Drupal\webform\EventSubscriber\WebformExceptionHtmlSubscriber::onException(Symfony\Component\HttpKernel\Event\GetResponseForExceptionEvent $event) should be compatible with Drupal\Core\EventSubscriber\HttpExceptionSubscriberBase::onException(Symfony\Component\HttpKernel\Event\ExceptionEvent $event) WebformExceptionHtmlSubscriber.php:31

> @douggreen I am not following changes are being made in #78.

#73 did not apply to 8.x-5.x-dev, #78 simply is a reroll that should apply.

But I like the idea of the smaller individual patches, I will try them tomorrow.

#82 adds .orig files again. - user error, sorry, some of the files don't apply cleanly, but do apply, so I get .orig files locally

I've been trying to track down these. Please use your constructors. This is _not_ how this interface is suppose to work and is a broken pattern.

Ugh, I'll follow up there. I'm trying to capture all these and push back. saying "the interface doesn't change" is not true. You're may not _explicitly_ be relying on the constructor's signature but you are implicitly relying on it. if you extend the object your are tied up in the constructor logic and there's no getting away from it.

Patch works but it needs a reroll after recent changes.

> Please provide an interdiff, so that I can commit the changes to 3067546-subclassing branch

It's not possible to provide a meaningful interdiff that would actually help you for a rebased patch. These rebases usually happen to apply it to projects, just ignore them and do your thing with the branch.

Just wondering, what's your timeline with the 6.0.x branch, when you do plan to start that?

Congratulations @jrockowitz!

*clap*

Fantastic work, everyone!