Handle Package Manager errors and warnings more elegantly

Fix in place.
Does this need a test?
Also - do we want to print warnings still? At the moment this is suppressing them.

We want to print warnings

Refactored the way we return messages from package manager to return errors and non-errors (warnings). If there are any errors, prevent installs and show the heading "Unable to download modules via the UI". If there are any warnings, we print them without a header.

I've added some screenshots of the various scenarios we could get if there are multiple messages. Chris informed me that we're unlikely to get both because of the way Package Manager works, regardless, the styles are in there just in case this happens.

Will have to work on tests later - any help in that department is appreciated!

Also left a review in the MR. Nothing big, but worth addressing or discussing.

Attached is a patch that _should_ add test coverage for both warnings and errors coming from package manager. I also attempted to merge the changes from the MR into this patch. I admit, I'm no Svelte expert, so there is a good chance I didn't do the JS stuff correctly.

Moved Phil's patch into the MR and fixed PHPCS errors

Test failures appear to be aligned with current failures against 1.0.x

Plan to refresh/rebase and review as this touches the code i'm working on here https://www.drupal.org/project/project_browser/issues/3451863

I'm still in progress cleaning up tests on this please message @sime in slack if you want to contribute or take over.

OK. So this was meant to be just a rebase, and it still is a rebase because I didn't really change anything from the work 6 months ago.

Code logic

I haven't really touched the code logic, but i did have to update the message handling in the svelte, since we are using the Drupal.messages() since the last work on this.

I'm hoping to get things back to where the code reviews were at, as I do think there is more work to do, but I also think it needs a review just to make sure committers are happy with test changes.

Tests

1. There were event listeners which triggered errors when calling ->validatePackageManager(). This reflected our code spending a lot of time in the package_manager validation - for no good reason, because we just needed mock message strings. So i mocked InstallReadiness instead, which means we are focussed on testing PB logic, instead of PM logic.
2. I was able to remove a todo from PackageManagerFixtureUtilityTrait->initPackageManager() - removing logic, because we can use the $modules property again, it seems.
3. Note that this currently includes #3453101: phpstan.neon.dist fixes - Get phpstan to level 1 just to help me wade through the errors.

I still have this assigned to myself just because if someone wants to pick it up it would be great to talk through the approach.

Some thoughts on next steps

1. Review the 6 month old unresolved comments
2. I think we should change the wording "messages" to "warnings" the same way that "errors" => "errors"
3. I think I have a plan for removing the need to isntall package manager, thus hopefully further reducing flakiness
4. Then maybe a separate Functional/integration test for how we interpreted package manager messages
5. There is one error that looks ugly - if composer validate throws errors.

Rebased and created new PR on 2.0.x branch.

I mostly resolved @fjgarlin's comments from 1.x MR

Non working state, removing from needs review.

Updated to 2.0.x (new branch). Old branch kept.

Just re-summarising this progress. The previous progress is still here against 1.x.

Testing strategy

Compared to the 1.x progress, I changed the way errors were mocked so that test logic did not need to go deep into Package Manager. So the updated tests are testing the scenario, using a mock, where InstallReadiness generates errors. This is testing how ProjectBrowser.svelte handles errors, rather than testing how PM generates errors.

The reason i changed the tests was because it was very flaky (intermittent time outs and failures) and slow for me (yes, even without xdebug). I think this remains a bigger problem with a lot of PB tests. PB tests often do full integration and maybe not necessarily. Since PM validation is slow I feel like most tests should be mocking what PM is doing. I don't think adding fake errors using event handlers is a good approach due to how much work PM is still expected to do (which contributes to intermittent timeouts of our tests).

But, well, long story short, I can revert how the tests are architected if asked. it was a journey for me to get them to work but i'm not wedded to my approach.

Message strategy

Instead of just setting status messages in PHP, we are turning them into strings and passing them to the svelte app, which then uses the javascript equivalent of setting the messages. We could just set these messages in PHP and remove about 20 lines of code. (I have tested this).

Now, regarding progress, the current 2.x code is still doing the same thing as a the 1.x code. With a couple of notes:

1. I did change the svelte app so that it clears (messenger.clear();) any current status messages just to avoid the screen getting filled with messages.
2. I aligned variable names so variables in constans.js have consistent package_manager_ prefixing

Installing test dependencies

Finally, a big thing in this MR is that it seems like we no longer need to install package_manager in a weird way via initPackageManager() and we can just use the $modules property.

This wasn't necessarily a goal of the issue, but there was a code TODO for it that I addressed in an effort to reduce the complexity of the code.

@phenaproxima has tightened the scope and it is looking good to me. I like the improvements in variable handling.

I have created a few extra tickets out of the things I learnt in the course of working on it.

#3455220: [REDO} Resolve technical debt in initPackageManager()
#3455215: ServiceProviderBase::alter shouldn't call parent::register
#3455210: Identify and action solutions for flaky tests

I'm just going to combined these up a little. It would be rare to have multiple errors here, I believe, so we'll just prefix each one and skip the extra ones?

Changes I made result in this:

The worst case scenario is two messages of the same type, thus showing the same prefix, but I think this is acceptable as it's very rare and looks fine.

For anyone who wants to manually test this, a simple way is to install the project_browser_test module.

1. You need this in your settings.php, note that it will start showing test modules/themes in the UI.

$settings['extension_discovery_scan_tests'] = TRUE;

2. Then install project_browser_test, I just use drush.

3. Now in TestInstallerReadiness.php in the onStatusCheck method, just change the code to manual create whatever messages you want to create.

Ya know, I think this is RTBC. Feels solid to me. Will let Chris have the final say.