Add facility to end emit task in the event of 404, 503 or 504 errors.

[garemoko]

404, 503 and 504 errors indicate a network connectivity or LRS load issue (or the endpoint is just wrong). In these cases, it may be desirable to have the emit task stop running and try again next time when hopefully the issues have been resolved.

Some considerations:

• It might be possible (especially with a 503 error) that the LRS load was such that it successfully stored the statement, but just failed to send a response. To avoid duplicated data, we should store either the whole statement, or just the statement ids so that the same ids can be re-used when re-sending.
• Waiting to send the statements adds risk to data being edited or deleted from the Moodle database in the meantime. This is another argument for storing the generated statements to re-send.
• If we do keep the statements, we also need to still keep the associated event in case we need to add it to the failed events list. (i.e. in the event of a 400 error when re-sending).
• In the event of these errors, it's possible not all requests sent by the task would fail. This will need to be handled appropriately.

[ryasmi]

Agree that we should ideally retry later for almost anything that isn't a 400 error. Regarding the storage of whole statements, are we actually able to do that in the databases used by users of the plugin? Usually there is some limit on string length and JSON fields are probably not allowed in most databases used by users of the plugin.

[garemoko]

Usually there is some limit on string length and JSON fields are probably not allowed in most databases used by users of the plugin.

Thanks. I wasn't aware of that.

[davidpesce]

With the jisc branch, failures and retries has been implemented.