Add options to handle database updates

I think running any available db updates should be default, after enabling the module, to complete the security update. In theory, the database update itself could be doing the plugging of a security hole, right? Essentially a drush up --security-only -y.

Database update options
x Run after updating files
  Put site in maintenance mode
  Do nothing

(^^ options are radio buttons)

In which scenarios would we want to roll back the update? Or do you mean roll back, if something fails?

The patch applies fine, and both Cron-triggered and the experimental link still updates the code from 8.7.4 to 8.7.9. But I get the error "The website encountered an unexpected error. Please try again later.", for both afterwards, and the db updates are not applied, but have to be applied manually.

+++ b/automatic_updates.module
@@ -141,3 +142,19 @@ function automatic_updates_mail($key, &$message, $params) {
+  if (function_exists('opcache_reset')) {
+    opcache_reset();

moreover apcu cache (used by autoloader by default) probably also need clean-up

Great job heddn, andypost and greg.1.anderson! I just updated from 8.7.4 to 8.7.10 by enabling "Enable automatic updates of Drupal core via cron" and running Cron. Also, there weren't any updates available at update.php, and this in the log files:

Database update handling has finished.
Database update finished with arguments "Array ( [0] => taxonomy [1] => 8702 [2] => Array ( ) ) "
Database update running with arguments "Array ( [0] => taxonomy [1] => 8702 [2] => Array ( ) ) "
Database update handling has started.

... so the available updates were applied.

I don't see any settings though, which is fine. But perhaps the Issue summary could have a bit of text about the solution which was decided on? Also the text on the admin/config/automatic_updates page says "Database updates are not run after an update.".

The only possible error I found was the warning I get after the update has run:

Warnings found
Update readiness checks
689 checks failed:
The hash for composer.lock does not match its original. Updates that include that file will fail and require manual intervention.
The hash for core/MAINTAINERS.txt does not match its original. Updates that include that file will fail and require manual intervention.
The hash for core/assets/vendor/ckeditor/lang/de.js does not match its original. Updates that include that file will fail and require manual intervention.
...

Flushing the cache didn't make a difference, but running the readiness check takes care of it. So perhaps it's working as designed, since the user should check if files are ready manually themselves, after an automatic update has been executed?

To make it compatible with Symfony 4.4+ command execute methods should return exit code.
See #3099295: Always return exit code in Symfony console commands for details.

Thanks for updating the Issue Summary. You all have really made a lot of progress, and it's coming along nicely. I'll test the patches in the other issues.