UX issues updating Joomla via CLI

[Hackwar]

We have the theoretical option to update Joomla via the CLI, however looking into this, I see several issues which are partially UX issues, partially bugs. I'm creating this issue, fully aware that this describes more than one problem, however I also think they are connected and should be described together. Yes, there are a few bug reports in here, but most of these are feature requests, so I'm marking it as such. Anyway, here we go:

Scenario for updating Joomla via CLI

Looking at our current CLI core update code, it seems as if the target for these features was not considered. If you are updating Joomla through the CLI, you are NOT clicking a button in the browser, surrounded by information about currently installed version and the update channel we are currently on. It is actually a feature that we would expect to be run by scripts and not strictly by people who have access to the backend of the site.

Issues

1. There is no command or parameter to change the update channel from the CLI. The CLI also does not return information on which channel you are right now.
2. Changing the update channel in the joomlaupdate configuration in the DB does NOT actually change the update source. You first have to open a view of com_joomlaupdate before that change is applied. You can not trigger this from the CLI. If you are in the browser, this also means that you can change the option in com_config, navigate to a different page than one from com_joomlaupdate and the setting will not be updated, resulting in the AJAX calls still returning the old version information.
3. While the command core:check-updates does return the available version number, it does not return the currently installed version and more importantly, the actual update command core:update doesn't return any version information.
4. core:update also hides most of the progress information by removing finished steps from the output again. To the user it looks like it is jumping from 1/8 Startup to 3/8 Downloading update package to 8/8 Cleaning up
5. It is not possible to see a list of available updates and to select a certain version to update to.
6. The update command does not delete the autoload_psr4.php file, resulting in errors after the upgrade.
7. Why do we have several commands for checking for the update and doing the actual update anyway? It looks like something that should be pushed into one command with proper parameters.

What should be done?

The core:update command should be greatly extended and the core:check-updates command should be deprecated. We should introduce a core:update:check command, which when called without parameters, returns the currently installed version, the currently selected update channel and the latest available version. With the parameter --channel=<channel> the update channel can be changed and in case of a custom URL, the --url=<url> parameter has to be added. The command should not only change the setting in the configuration, but also update the updatesite, as necessary.
The core:update command should be much more verbose with its output. It should display the currently installed version, the update channel and the version of the update which would be installed and should then ask for confirmation to actually run the update. This should be surpressable with a switch. The output should not be hidden in the progressbar and if given the verbose switch, it should actually provide additional information, maybe even down to the files copied. Another switch should allow to select which update to install. If the update process encounters errors, it should return hints at the basic issue to the console.
The process should delete the autoload_psr4.php properly. The code of the commands itself should really be reviewed and cleaned up. Right now it is pretty messy and could really benefit from a cleanup.

[Hackwar]

With the PRs #42601, #42597 and #42594 this issue is largely solved. Closing this.