We can now use the autocomplete element to select the user. No need to
for the legacy behaviour.

The module provides AJAX support for the autocomplete form element.

The purpose of this external function is to provide data for
asynchronous user selectors and similar widgets. It allows to search
users matching the given query in their name or other available identity
fields.

Not related to this issue, just spotted while working on it.

I suppose the original reasoning was that the web services protocols are
pluggable and that plugins can provide external function. But those are
not good reasons to put the whole Web services section under plugins.
Web services are not a plugin type and they always felt very
counter-intuitive there.

From the server administrtaion perspective, web services are similar to
scheduled tasks and therefore, they should live in the same section.

Manage backpacks page wasn't displaying the navigation and administration
menus when using classic theme (it's unrelated to changes done here).
This patch fixes this unexpected behaviour (raised thanks to behat tests).

jun authored Mar 10, 2021 and Sara Arjona committed Mar 10, 2021

Since cm_info::customdata can be of any type, we need to cast it to an
array first before checking for custom completion rules. Otherwise,
an exception can be thrown (e.g. customdata has been set as an stdClass)

In all cases changes have been kept to a minimum while not making
the code completely horrible. For example, there are many instances
where it would probably be better to rewrite a query entirely, but
I have not done that (in order to reduce the risk of changes).

The $CFG->badges_site_backpack setting has been completely removed
because it's not required anymore. From now, the primary site
backpack will be the first one in the "Manage backpacks" list (so,
the one with lower sortorder value).

Before removing $CFG->badges_site_backpack setting, admins should be
able to re-order the existing site-backpacks (because then, the first
one will be treated as the default one).
This patch adds the sort order feature to the backpack list.

Use the custom completion implementation for mod_choice to test
completion_info::get_state() to cover the case where the completion
state is being determined from the custom completion condition.

* Update completion_info::get_data() to add other completion
information from a new method called get_other_cm_completion_data().
This allows the storage of the completion statuses of the following
completion rules to completion_info objects:
  - 'Students must receive a grade' completion rule.
  - Any custom completion rule defined by an activity.
This allows detailed completion information to be fetched for course
modules.
It also allows custom completion statuses to be cached which will help
reduce DB queries when fetching completion statuses.
* Update update_state() to fetch overall completion state from the
module's activity_custom_completion implementation. Falls back to the
*_get_completion_state() callback function.
* Update internal_set_data() to include the other cm completion data
in the updated cache data for the module instance.

Move the current logic for determining the completion status for the
"Student must receive grade" completion rule to a function so it cann
be reused.
Unit test included.

* Unit tests for completion_info::get_data() and
completion_info::internal_get_state are mocked which causes failures
with the new implementation. It's more straightforward and realistic
to generate real course and modules to test these methods.

Tests cover
 - get_overall_completion_state()
 - is_available()
 - validate_rule()
Tests don't cover
 - methods that rely on static methods such as:
   - is_defined()
 - static methods in the class because they can't be mocked
 - abstract methods that can be tested better by the plugins
   that extend activity_custom_completion such as:
   - get_state()
   - get_defined_custom_rules()
   - get_custom_rule_descriptions()

* Base class for defining an activity module's custom completion details