[PP-1] Add Alpha level Experimental Automatic Updates module

Please DO NOT push to this branch. See How to Help for instructions for working in the contrib module.

Problem/Motivation

Automatic Updates is one of Drupal Core current strategic initiatives. For full details of the initiative, see #2940731: Automatic Updates Initiative overview and roadmap.

Currently the work on the module is happening in 3.0.x branch of the Automatic Updates contrib module.

This issue is to bring in the current version of the 3.0.x branch of the contrib module into core as an Alpha level experimental module.

Proposed resolution

This merge request also includes the Package Manager module which it depends on from #3346707: Add Alpha level Experimental Package Manager module

The merge request on this issue is created automatically from the 3.0.x branch of the contrib module.

Since this is will be a very large merge request we will continue to create issues and make improvements in the contrib module 3.0.x branch and convert that work via the conversion script to commits here. @tedbow or @phenaproxima will make the conversion daily if there are commits to the contrib module.

#3346707: Add Alpha level Experimental Package Manager module will have to be committed first, but this issue is open so that reviewers of that issue can see the Package Manager's API in use by Automatic Updates.

What does Automatic Updates do?

Package Manager does the underlying heavy lifting of automatic updates (that is, copying the codebase to a sandbox, making changes there, then bringing those changes back into the main codebase), but it provides no UI of its own. It also has no opinion about what kinds of changes are made to the codebase.

Here's what Automatic Updates itself does:

• Provides a UI. It replaces the core Update module forms with a form that lists available updates and invokes Package Manager to kick off an update, assuming all the required preconditions are met. For example, a number of constraints are enforced here: are you on a stable release of core (you cannot update from a dev snapshot)? Is the filesystem writable? Once you start an update, Automatic Updates sets up a batch job for it, which calls Package Manager as needed to guide the user through the process. If a user updates in the UI, they also have the option to the next minor version of core (for example, from 10.1.3 to 10.2.0) -- although, for safety's sake, this functionality has to be enabled by a config flag.
• Provides the ability to do updates in the background, unattended. They can either be kicked off by Automated Cron (or the /system/cron page), or by an additional crontab entry that calls a terminal command we supply (vendor/bin/auto-update, which will likely be folded into core/scripts/drupal when Automatic Updates is stable in core). The benefit of this is security -- it allows the codebase to be modified by a different system user than whichever one the web server runs as. The trade-off is that it's more complicated to set up. Background updates are more tightly scoped than UI updates -- when doing a background update, you can only update to new patch releases in the same minor, since updating across minors is riskier. Background updates can also be configured to happen only if there's a new security update -- this is the default behavior, because we're assuming that your main goal, as a site maintainer, is to keep Drupal secure.
• If background updates fail, or cannot be started at all due to unfulfilled preconditions, Automatic Updates will notify the site owners by email. It will also notify the site owners when a background update is successfully completed.
• One thing Automatic Updates doesn't do is update contrib modules and themes. There are some unresolved problems with this, and it's not in scope for the initiative. The functionality does exist in contrib, as the Automatic Updates Extensions module. (Currently this is a submodule of Automatic Updates, but will be a separate project in contrib once Automatic Updates is in core.)
• Another caveat is that we don't allow background updates on Windows systems, because they have to be executed differently than on *nix environments. Once we have the ability to run tests on Windows, we should be able to lift this restriction. If you try to do a background update on Windows, it will fail with an error and won't start.

What can you update?

Automatic Updates only updates Drupal core. It imposes many constraints on what versions of core you can update to and from. This isn't exhaustive, but here's the basic idea:

• You cannot update if you are running a dev snapshot of core.
• You cannot update to a different major version.
• You can't downgrade. That is not a thing in Drupal.
• You cannot update to a release of core that is unpublished, unsupported, or insecure.

Background updates have even more restrictions:

• You must be running a stable version of core to do a background update. You cannot be running an alpha, beta, or RC.
• You also have to be updating to a stable version of core. You can't update to an alpha, beta, or RC.
• You cannot do a background update to a newer minor version of core; there is too much of a risk of things breaking without your knowledge.
• You cannot do a background update to a version of core that has database updates. Because of the potential for serious breakage, you have to use the UI to do these sorts of updates. Unfortunately, this is something we can only detect while we're in the middle of the update (we statically analyze the incoming version of core to see if it has any database updates, and if it does, we delete the sandbox and fail with an error).

How to help

Feel free to leave feedback on this merge request. If you would like to help address the feedback please search the 3.0.x issue queue to see if any existing issue exists and if not create one in that project.

Remaining tasks

The functional test are currently not passing because of the core bug #3392196: Exceptions in batch no longer are shown on the page. This issue must be fixed for the functional tests here to pass.

1. Review the patch
2. Framework manager sign-off
3. Release manager sign-off