If recording is removed or updated in the server, the value is not updated in Moodle

Since the way recordings are fetched was redesigned for 2.5, and it is now based on a cache, there is a flaw that shows up when the recordings are managed outside Moodle.

This normally happens when automated management actions ( in the BBB servers) are performed on recordings, but can be easily be reproduced using API-mate.

How to reproduce it:

• Create a new activity with only default values, launch into BBB and record the meeting
• Wait until the recording shows up and playback the recording
• Take note of the recordingID that appears as the last segment in the URL. It should look like this (65ecbe7db33b3a652a7c5df7ded146687f50e8de-1637605116096)
• Open api-mate https://mconf.github.io/api-mate/, change the BBB credentials, remove the random meetingID and replace the recordID with the one obtained from the actual recording.. Then click the link to publish the recording (which will actually unpublish it)
• Go back to moodle and try to playback the recording again, you should get a 404
• On Moodle unpublish the recoding, now it is in sync again
• On Moodle publish the recording again, and On API-mate click on the link to delete the recording
• Go back to moodle and try to playback the recording again, you should get a 404
• On Moodle unpublish the recoding, now it is in sync again, but since the recording is deleted the data shown now is incorrect

Here is a video that describes how to reproduce the problem and why is this a problem contrib-8777.mp4

I should point out that the solution is not necessary to destroy the recording in Moodle  when the request comes as deleted, because in some cases there will be no delete, but the playback format may be replaced.So, what we need is a mechanism to expire the cache, so a getRecordings is performed again to keep the data in sync