Fix errors and bugs in RevokePriorityModule

[violine1101]

Purpose

This addresses multiple issues with the RevokePriorityModule:

• The module would error if it encountered an outdated priority value in a changelog
• The module would succeed and try to reset priority even if priority hasn't been changed recently
• The module would consider all changes in the changelog to be authoritative if they're more than one day old - since the changelog isn't accurate for Mojang Priority it shouldn't do this.

Approach

Added more checks:

• The module now checks if any changes to mojang priority have been made since last run
• The module now checks that the priority from the changelog is a valid priority, and otherwise logs an error (for manual correction)
• I've increased the limit for old priority changelog items to be considered canonical from one day to one year. This is not perfect! But it should be better than before, where as a regular user you could unsuccessfully try to change priority 2 days in a row, and on the second day Arisa would perform the change for you.
  In this case I'm not sure if it even makes sense to still have the updateIsRecent check there. Since the changelog is messed up for mojang priority I don't see any other way though without it getting more involved.

Future work

Perhaps we should disable this module and only enable it when it is needed?

Checklist

• Included tests
• Updated documentation in README and docs folder
• Tested in MCTEST-xxx

[Marcono1234]

To avoid duplication, what about having a map from priority name to ID, which is then used by getId, and isValidPriority could use the values of the map instead.

[Marcono1234]

I am a bit worried what happens when a new priority is added, and when a Mojang employee then changes the priority of an issue (which is not "None") to that new priority. To me it looks like this assertion here would erroneously consider them unequal because getId would return "-1", even though the new priority is the same set by originalPriorityItem.

Is there a way to obtain the priority ID from the issue? If not, would one of these implementations make sense?

• compare priority names instead (or maybe only as fallback if the ID for the priority cannot be determined)
• change getId to return String? and don't try to revert the priority change if the result of getId for the new priority is null
• check the changelog to verify that the last change was not done by a staff member (might be error-prone?)

[violine1101]

In theory, in this case, priority should always be equal to originalPriority, since that's both the most recent staff priority changelog item and the current priority of the issue.

Aka, priority is always the already updated priority, not the priority from before the change. Which is what makes things tricky.

E.g. Mojang developer changes priority from None to Normal:

• priority is now 11702
• originalPriorityItem is `None [-1] -> Normal [11702]
• originalPriorityId is 11702

Thus this check would fail and the module would return OperationNotNeeded.

[Marcono1234]

The case I was thinking of is:

A new priority "Extremely Important" with ID 11699 is added, and a Mojang developer changes the priority of an issue to "Extremely Important". originalPriorityId is therefore "11699" and priority is "Extremely Important". However, because getId does not know the ID for "Extremely Important", it returns "-1", which is unequal to "11699", and therefore the module erroneously reverts the change.

Or am I misunderstanding something here?