Automatic updates: For MVP, instead of an a/b bootloader, implement a semi-atomic composer update with a brief maintenance-mode window

Problem/Motivation

See #2940731: Automatic Updates Initiative overview and roadmap for the larger context of the Automatic Updates initiative.

• For this issue, the goal is to allow automatic updates to be performed on a production site, meaning a site that is serving requests while being updated. This is for the benefit of the majority of Drupal sites, which are on a single server (whether shared hosting, VPS, or dedicated) with only a production environment and no existing deployment process other than manually copying new Drupal releases (whether via FTP or git pull or whatever) onto the production server. This is not for sites with advanced hosting, such as sites with multiple web nodes, dev/stage/prod environments, or required deployment processes, because those sites will either not run Drupal core's automatic updates at all, or will run them in a non-production environment and then trigger their existing deployment processes to deploy to production.
• For the case where we're performing the update directly on the production environment, we need to prevent the situation of production requests being served (other than ones deemed sufficiently safe, such as page cache hits or the "your site is in maintenance mode" message) while the site's codebase is in an in-between state (e.g., while a composer update is in progress).
• The most robust way to do this is with an a/b bootloader. #3093093: Replace single index.php with a frontend controller that supports A/B updating (automatic updates) is the issue for that. The idea of that is that instead of a single docroot directory and vendor directory, you have an "a" copy and a "b" copy of each, and an index.php file that routes to one of them while an update is performed on the other one, and then the index.php file switches which one it routes to after the update is finished. However, there are a number of challenges with implementing that, which I won't comment on here, but we should update that issue's summary with a list of what those challenges are.
• In this issue, we (the Automatic Updates initiative team) are proposing an alternative solution that's slightly less robust, but easier to implement, which we recommend doing as an MVP. See the Proposed Resolution for details.

Proposed resolution

• Create a Composer plugin that performs an update by first copying the working directory (the directory where the root composer.json file is) to a temporary directory, performing the composer update in that temporary directory, and then efficiently copying (e.g., with rsync or similar) all changed files back to the original working directory. This reduces the amount of time that the working directory is in an in-between state to the duration of the rsync (or similar) operation, rather than the duration of a composer update.
• Although an rsync is fast, it's not perfectly atomic. Therefore, we also want this Composer plugin to invoke events just prior to and just after the rsync, so that the automatic updates module can put the site into maintenance mode during the rsync to prevent the site from executing production requests during that brief window.
• We need to exclude from the rsync operation directories that contain content files rather than code files. In other words, files that are written as part of the normal operation of the production site, such as the sites/default/files directory. This is because the contents of these directories can change on the production site while the composer update operation is happening in the temporary directory, and we don't want to revert those production site changes when we rsync back from the temporary directory.

Remaining tasks

• See the current proof of concept. As a proof of concept, there's plenty that's still missing (such as the events mentioned in the proposed resolution above) or wrong (such as the hard-coding of web/sites/default/files) with it.
• I will start opening GitHub issues for remaining things to do. If anyone else wants to open issues and/or pull requests there, please do.
• Meanwhile, in this drupal.org issue, please comment with whether you agree with or have concerns about the approach in general.

User interface changes

API changes

Data model changes

Release notes snippet