If an update failed to apply don't allow more use of the module

I am not sure if this solution should be in package_manager or Automatic Updates

Right now if a Drupal core update failed in the middle of an apply this would be very bad and your site should be restored from a back up.

On the other hand depending on how Project Browser uses Package Manager they could just copy over only the new module that was required. They could be very strict about checking to see if no Composer dependencies and other projects were added or updated. in that case if they were just using the new module directory as active/stage targets then if it failed to apply the folder could just be deleted and the user could try again. Drupal core or other code would not be affected.

UPDATE:
I just realized that if we don't have the PACKAGE_MANAGER_UPDATE_FAILURE.txt file then even though Project Browser won't affect core or other modules if it is installing new_module sub-sequent web requests there would be now way to tell that new_module had failed to be fully copied in.

So maybe PACKAGE_MANAGER_UPDATE_FAILURE.txt should be set by package_manager and it should be up to other modules to determine how to respond.

Actually maybe we should have PACKAGE_MANAGER_OPERATION_FAILURE.json. this that file we could have info like
which module was doing the operation and the time it started, etc

Currently this MR creates the file that we want but it does not actually prevent another operation from going forward.

There is no check to be sure that if this file exists then Package Manager should not allow any operations.

so either we have to make an event subscriber to listen to PreCreate and stop new operations if the file exists. We would probably also want to a AutoUpdates Readiness check to also check this file.

Also we should add a check to package_manager_requirements() to check for this file on $phase === 'runtime'

so this means we would need to hard code the name of this file multiple places. Currently it is just in Stage.php.

So lets create an event subscriber validator in package_manger that does 1.

1. On PreApply create the marker file, we can remove this logic then from Stage.php. It would be good if this event happened last, see Symfony Event priorities
2. It should listen to PreCreate and check if the file is present and add a validation error if it is
3. This class should have public method deleteFailureMarker() we will call this from stage.php. This means we will have to add the new validator service as a dependency of the Stage class in its constructor.

Then we need kernel test for this validator that would

1. Running stage operation that would fail with a ApplyFailedException thus leaving our mark fail in place
2. Call Stage::delete() and then try to create run another stage operation. It should be impossible because our PreCreate should detect the marker fail.

The only thing this proposed test makes wonder is if we should actually prevent Delete if the file is present, something to think about later.

We still have the problem I mentioned in #2 but we can wait on that.

Needs work. Suggested in the MR to open up a 2nd merge request for a different approach. see https://git.drupalcode.org/project/automatic_updates/-/merge_requests/39...

@yash.rode thanks for the making the new MR to move everything into stage.

We also need to stop \Drupal\package_manager\Stage::create and \Drupal\package_manager\Stage::claim from working if there is a marker file. I think they can both call a new method. `ensureNoFailedApply()` or a better name. That method should throw an exception if a marker file exists.

Then we would need test coverage for that.

Basically after a update failed to apply if you tried to claim the stage or create a new 1 you should get this exception.

It think we should also figure out if we can handle this in \Drupal\automatic_updates\Form\UpdaterForm one way would be to call `ensureNoFailedApply()` and if there is an exception tell the user in the UI that there was a failed exception.

Needs work for MR comments

@yash.rode sorry this is tricky issue but an important one. But I think we are pretty close