Remove creation of calendar events for mod_assign with
eventtype = 'open'. Since mod_assign instance creation only creates a
calendar event for the due date, there's no point in creating an override
event for an event type that does not exist.
If there are multiple, non-repeating events with the same module name,
instance and event type. The most specific event or the event with the
highest priority will be shown.
The ordering of event priorities:
User override events > Group override events > Course events.
If there are no user override events and there are multiple group
overrides for an event, then the one with the highest priority will be
shown.
Set the event priority of the following activity overrides:
* mod_assign
* mod_lesson
* mod_quiz
Always create separate events for start and end dates of activities.
* New priority column in order to enable the rendering of a single,
relevant calendar event for a module that has user/group overrides.
* Insert refresh_mod_calendar_events_task record to task_adhoc
table to upgrade existing calendar events for mod plugins via cron
after upgrade process.
New module functions quiz_get_group_override_priorities() and
lesson_get_group_override_priorities() to calculate the priorities
of group overrides for a quiz/lesson activity.
When the course category cache needs to be repopulated, two entries are added
to the cache for each category. In core this is currently done in a for-loop,
resulting in N set calls to the cache (where N is twice the number of
categories in Moodle).
This change switches that code to using a single set_many cache call instead,
which makes this an O(1) operation instead of O(N).
For a site with say, 1000 categories, this results in only 1 set call to the
cachestore instead of 2000.
It is now safe to cache a reference to a cache and expect consistent results.
Changing identifiers altered cache results where a reference was
held to the cache. Identifiers have been set to be cached with
identifiers included so the caches are separate.
As a consequence of this it was identified that invalidation events
and identifiers don't easily work together as an event can't determine
which identifiers should be used for cache invalidation. So invalidation
events have been made incompatible with identifiers being set. No core
code used this combination as it's not possible to understand any expected
behaviour.
Event invalidation for application and session caches was centralised to the same
location. The only difference was the name of the lastinvalidation variable. This
improves support and consistency of invalidation code.
