Allows display_size to use a fixed unit for easy comparison of
multiple results, and fixed decimal places for the same reason.

Improves behaviour by using consistent decimal places and a
consistent space before the unit (the previous one only has a space
before 'bytes', not before 'KB').

Of existing uses, all the ones that displayed a 'maxbytes' type
configuration setting (which are likely to have an 'exact' size
and would be better shown as 512 KB rather than 512.0 KB) have been
changed to use 0 decimal places, to preserve previous behaviour.
All the uses which were showing an actual file or memory size have
been left as default (1 decimal place).

Update existing code to set type to warning as appropriate.

The Flash Player was deprecated in 2017 and officially discontinued
on 31 December 2020, so media_swf player has been completely
removed from Moodle core.

As the message_jabber notification plugin has been removed from core,
the XMPPHP library (aka Jabber) is not required any more so it has
been completely removed from Moodle core too.

This implementation will introduce a qbank plugin "previewquestion"
which will view the preview question action in the question bank
actions by replacing the core classes, scripts and yui modules.
This plugin will also replace the preview option in the edit
question form. Having this plugin will give users the
flexibility of enabling or disabling this feature from
the question bank view.
This change will also allow other qbank plugins to add
elements or information in the preview question page
by implementing a callback. It also changes the pop
up to page redirect from base view page to make sure
any changes in preview reflects in the base view, for
example, comments added and the number of comments in
the comments colum changes while back from the preview
page. Other locations like edit and qtype plugins where
the preview is implemented, stays the same.
Co-Authored-By: Guillermo Gomez Arias <guillermogomez@catalyst-au.net>
Co-Authored-By: Safat Shahin <safatshahin@catalyst-au.net>

This implementation will introduce a qbank plugin "managecategories"
which will add the question categories feature in the question bank view
by replacing the core classes. Having this plugin will give users
the flexibility of enabling or disabling the category tab.

Add optional argument to allow it to be defined by caller, and set
the default icon for `select` type as appropriate.

* ensure message_send returns false if message not sent
* digests only clear queue on success
* notifications requeue failed messages

The method allows to check if the user is fully ready to use the site or
whether there is an action (such as filling the missing profile field,
changing password or agreeing to the site policy) needed.

Final deprecation of generate_uuid function.

lib/upgrade.txt was updated to reflect the fact that all cURL redirects
will be emulated.

For activity based course completion criteria allow instant
course completion updates if the activity completion state was changed
for a single user.

The legacy M.core.event.BLOCK_CONTENT_UPDATED event has been replaced with a
new core_block/events::blockContentUpdated native DOM event.

The new event can be triggered using the `notifyBlockContentUpdated`
event, and by providing the HTMLElement that was updated, for example:

```
import {notifyBlockContentUpdated} from 'core_block/events';

const someHandler = e => {
    // ...
    const updatedBlock = e.target.closest('.block');
    notifyBlockContentUpdated(updatedBlock);
};
```

The new event can be listened to at any point in the DOM using the
following syntax:

```
import {eventTypes} from 'core_block/events';

const handler = e => {
    // The block that was updated.
    e.target;

    // The id of the updated block.
    e.detail.instanceId;
};

document.addEventListener(eventTypes.blockContentUpdated, handler);
```

A backward-compatabibility layer is included to ensure that any legacy
YUI event listener is still called with the same arguments.

This legacy bridges will be removed after Moodle 4.3.

The legacy M.core.event.FILTER_CONTENT_UPDATED event has been replaced with a
new core_filter/events::filterContentUpdated native DOM event.

The new event can be triggered using the `notifyFilterContentUpdated`
function, and by providing with an Array containing the HTMLElements
that were updated, for example:

```
import {notifyFilterContentUpdated} from 'core_filter/events';

const someHandler = e => {
    // ...
    const nodeList = Array.from(document.querySelectorAll('div'));
    notifyFilterContentUpdated(nodeList);
};
```

The new event can be listened to at any point in the DOM using the
following syntax:

```
import {eventTypes} from 'core_filter/events';

const handler = e => {
    // The list of HTMLElements in an Array.
    e.detail.nodes;
};

document.addEventListener(eventTypes.filterContentUpdated, handler);
```

A backward-compatabibility layer is included to ensure that any legacy
YUI event listener, or jQuery event listener are still called with the
same arguments.

This legacy bridges will be removed after Moodle 4.3.

The legacy M.core.event.EDITOR_CONTENT_RESTORED event has been replaced
with a new core_editor/events::editorContentRestored native DOM event.

The new event can be listened to at any point in the DOM using the
following syntax:

```
import {eventTypes} from 'core_editor/events';

document.addEventListener(eventTypes.editorContentRestored, handler);
```

A backward-compatabibility layer is included to ensure that any legacy
jQuery event is still called with the same arguments.

This legacy bridge will be removed after Moodle 4.3.

The legacy M.core.event.FORM_SUBMIT_AJAX ecent has been replaced with a
new core_form/events::formSubmittedByJavascript native DOM event.

The new event can be listened to at any point in the DOM using the
following syntax:

```
import {eventTypes} from 'core_form/events';

document.addEventListener(eventTypes.formSubmittedByJavascript, handler);
```

A backward-compatabibility layer is included to ensure that any
legacy YUI event triggered on a form is still respected and the new
native event is also fired.

A similar handler is also included to ensure that any legacy YUI event
listener is still called with the same arguments.

These legacy bridges will be removed after Moodle 4.3.

This isn't really a deprecations where something is replaced
by another and all uses must adapt to. Instead it's just a
fallback functionality that will stop working in Moodle 4.2.

Because of that, I've tried to add TODO/@todo comments to
the places that will need to modified, always pointing to
MDL-71421 that is where the removal will happen.

Also, haven't added any debugging() output, after thinking
a lot about it, because this isn't anything that developers
can be using but a internal implementation detail (a fallback)
that we want to remove in some versions.

This adds the requirement for activities supporting custom completion to
specify the order all completion conditions should be displayed for that
activity. It also implements the sorting that takes place.

Peter Burnett authored Mar 05, 2021 and Eloy Lafuente committed Apr 18, 2021

This adds a new webservice that creates gradecategories as a batch,
and deprecates the old single creation call, which is superseded.
It also patches a few small issues in the single WS, for any integrations
currently relying on that webservice.

Augument all installed plugin's security helper if there is any.
Plugins function has to be defined as plugintype_pluginname_security_helper in pluginname/lib.php file.

This class would belong more appropriately within the 'user' API
(core_user) instead of within the 'core' API, since it is
directly related to user data.

Since the class has only just been added to Moodle, now is a good
time to move it.

If the 'methodname' is not explicitly specified in db/services.php,
expect it to be 'execute'.

Implement the new secondary nav and curate the nodes from flatnav and settingsnav

Modifies the 'string time to timestamp' behat trasformation to use
userdate() instead of date(). The userdate() method is generally used
throught Moodle for constructing formatted date strings and this change
will provide more consistency and prevent any potential behat failures.
Therefore, if the date format is defined in the given trasformation, it
has to be strftime compatible. Example:
'I should see "##tomorrow noon##%A, %d %B %Y, %I:%M %p##"'

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