The plugins check screen now provides buttons to cancel installation of
a plugin. Available only for new installations (not upgrades) and for
additional plugins (not standard), given that the web server process has
write access to the plugin folder.

This has also been reported as MDL-48535.

As a part of the patch, there is improved processing of page URLs during
the upgrade. All this dancing around $reload URL is not needed once the
$PAGE->url is properly set to guide the admin on the correct page during
the upgrade process.

This is not really new class. Originally, the validator was implemented
in the scope of the tool_installaddon plugin. But we need its features
in other parts at the core level (e.g. during the upgrade to validate
available missing dependencies or available updates). Looking back, it
was a mistake to have it implemented at the plugin level rather than the
core level.

So this patch moves the tool_installaddon_validator class to
\core\update\validator class, together with associated unit tests,
fixture files and strings. There were changes made in the
tool_installaddon to make use of this new class instead of the old one.

This is a great step towards the bright future, hopefully there won't be
many regressions.

AMOS BEGIN
 MOV [validationmsg_componentmatch,tool_installaddon],[validationmsg_componentmatch,core_plugin]
 MOV [validationmsg_componentmismatchname,tool_installaddon],[validationmsg_componentmismatchname,core_plugin]
 MOV [validationmsg_componentmismatchname_help,tool_installaddon],[validationmsg_componentmismatchname_help,core_plugin]
 MOV [validationmsg_componentmismatchname_info,tool_installaddon],[validationmsg_componentmismatchname_info,core_plugin]
 MOV [validationmsg_componentmismatchtype,tool_installaddon],[validationmsg_componentmismatchtype,core_plugin]
 MOV [validationmsg_componentmismatchtype_info,tool_installaddon],[validationmsg_componentmismatchtype_info,core_plugin]
 MOV [validationmsg_filenotexists,tool_installaddon],[validationmsg_filenotexists,core_plugin]
 MOV [validationmsg_filesnumber,tool_installaddon],[validationmsg_filesnumber,core_plugin]
 MOV [validationmsg_filestatus,tool_installaddon],[validationmsg_filestatus,core_plugin]
 MOV [validationmsg_filestatus_info,tool_installaddon],[validationmsg_filestatus_info,core_plugin]
 MOV [validationmsg_foundlangfile,tool_installaddon],[validationmsg_foundlangfile,core_plugin]
 MOV [validationmsg_maturity,tool_installaddon],[validationmsg_maturity,core_plugin]
 MOV [validationmsg_maturity_help,tool_installaddon],[validationmsg_maturity_help,core_plugin]
 MOV [validationmsg_missingcomponent,tool_installaddon],[validationmsg_missingcomponent,core_plugin]
 MOV [validationmsg_missingcomponent_help,tool_installaddon],[validationmsg_missingcomponent_help,core_plugin]
 MOV [validationmsg_missingcomponent_link,tool_installaddon],[validationmsg_missingcomponent_link,core_plugin]
 MOV [validationmsg_missingexpectedlangenfile,tool_installaddon],[validationmsg_missingexpectedlangenfile,core_plugin]
 MOV [validationmsg_missingexpectedlangenfile_info,tool_installaddon],[validationmsg_missingexpectedlangenfile_info,core_plugin]
 MOV [validationmsg_missinglangenfile,tool_installaddon],[validationmsg_missinglangenfile,core_plugin]
 MOV [validationmsg_missinglangenfolder,tool_installaddon],[validationmsg_missinglangenfolder,core_plugin]
 MOV [validationmsg_missingversion,tool_installaddon],[validationmsg_missingversion,core_plugin]
 MOV [validationmsg_missingversionphp,tool_installaddon],[validationmsg_missingversionphp,core_plugin]
 MOV [validationmsg_multiplelangenfiles,tool_installaddon],[validationmsg_multiplelangenfiles,core_plugin]
 MOV [validationmsg_onedir,tool_installaddon],[validationmsg_onedir,core_plugin]
 MOV [validationmsg_onedir_help,tool_installaddon],[validationmsg_onedir_help,core_plugin]
 MOV [validationmsg_pathwritable,tool_installaddon],[validationmsg_pathwritable,core_plugin]
 MOV [validationmsg_pluginversion,tool_installaddon],[validationmsg_pluginversion,core_plugin]
 MOV [validationmsg_release,tool_installaddon],[validationmsg_release,core_plugin]
 MOV [validationmsg_requiresmoodle,tool_installaddon],[validationmsg_requiresmoodle,core_plugin]
 MOV [validationmsg_rootdir,tool_installaddon],[validationmsg_rootdir,core_plugin]
 MOV [validationmsg_rootdir_help,tool_installaddon],[validationmsg_rootdir_help,core_plugin]
 MOV [validationmsg_rootdirinvalid,tool_installaddon],[validationmsg_rootdirinvalid,core_plugin]
 MOV [validationmsg_rootdirinvalid_help,tool_installaddon],[validationmsg_rootdirinvalid_help,core_plugin]
 MOV [validationmsg_targetexists,tool_installaddon],[validationmsg_targetexists,core_plugin]
 MOV [validationmsg_targetexists_help,tool_installaddon],[validationmsg_targetexists_help,core_plugin]
 MOV [validationmsg_unknowntype,tool_installaddon],[validationmsg_unknowntype,core_plugin]
 MOV [validationmsg_versionphpsyntax,tool_installaddon],[validationmsg_versionphpsyntax,core_plugin]
 MOV [validationmsglevel_debug,tool_installaddon],[validationmsglevel_debug,core_plugin]
 MOV [validationmsglevel_error,tool_installaddon],[validationmsglevel_error,core_plugin]
 MOV [validationmsglevel_info,tool_installaddon],[validationmsglevel_info,core_plugin]
 MOV [validationmsglevel_warning,tool_installaddon],[validationmsglevel_warning,core_plugin]
AMOS END

The plan is to have a single tool looking after all operations with
plugin ZIP packages (downloading, unzipping, moving to the dirroot and
back). For legacy reasons, we have that logic currently duplicated in
mdeploy and tool_installaddon. I would like to unify and simplify the
whole machinery to use the same code for available updates, manual
installation and plugin dependencies.

The patch improves the dependencies resolution in the plugin manager so
that the information about availability of the missing dependency is
included and can be displayed at the Plugins check screen during the
upgrade.

The purpose of this class is to provide a general client for all APIs
available at https://download.moodle.org/api/ (e.g. available updates,
plugin info, plugins list etc). Currently, fetching data from this API
is done separately at several places. This leads to code duplication and
harder maintenance (I know it well).

Additionally, the existing client was implemented as
tool_installaddon_pluginfo_client in the admin/tool/installaddon/ scope.
I will soon need to use the same functionality in the
core_plugin_manager and it would hurt my karma if the core was depending
on a class provided by a admin tool plugin (even if it is standard one).

So, there is new \core\update\api client implementing the version 1.3 of
the pluginfo API. There is a TODO note left for remaining services.

The patch moves the resolving logic from the renderer (where it should
not really be) to the plugin manager (controller). This is needed
because we will need the very same logic to be used at other places.

The actual loading of available updates info objects is moved back to
the plugin manager class. As we can now mockup the manager in unit
tests, this allows us to bypass the real \core\update\checker and have
unit tests for \core\plugininfo\base::available_updates().

Plugin info objects are owned by the plugin manager (composition
pattern). Even if the plugin manager is a singleton, we need to keep
explicit reference to the plugin manager that owns the plugin info so
that we can mock up things in unit tests.

Therefore this patch introduces a new property of plugin info objects
that holds the reference to the instance of the plugin manager that made
(and hence owns) the given info instance.

The only trouble here is with static methods of plugin info classes such
as \core\plugininfo\base::get_enabled_plugins(). In these cases, the
code keeps using the core_plugin_manager singleton. The solution would
be to pass the plugin manager instance as a parameter but that is not
worth of change for now, IMHO.

We can now override the plugin manager's methods in the testable
subclass while still keeping the singleton behaviour of it. The change
makes use of late static binding.

Before this patch, whenever core_plugin_manager::get_plugins() was
called, it always attached info about available updates. But this is
needed only in quite rare cases, such as when the admin is looking at
the Plugins overview and Plugins check screens. There is no need to load
this on other places and for non-admin users.

The patch removes the loading from the method
core_plugin_manager::get_plugins_of_type() and implements lazy loading
directly in the plugininfo classes so that it is loaded only when
\core\plugininfo\base::available_updates() is actually called.

The method should check against $CFG->disableupdatenotifications and not
$CFG->disableupdateautodeploy. This had to be a copy&paste mistake from
the \core\update\deployer::enabled().

While looking at it, I also fixed couple of places where this method
should and could be used.

The intention here is to make the table a little bit more compact (using
less columns) and to make use of the bootstrap based label elements if
available.

Conflicts:
	lib/upgrade.txt

Conflicts:
	version.php