#1120 Improvements for Reviewer stats updates

[CarlosNZ]

Fix #1120

Main changes:

• Remove the "Insert" trigger for review_assignment and review_assignment_assigner_join, as this was causing the update function to run way too many times[^1] whenever review assignments were generated. Instead it just gets run once and is called by the generateReviewAssignments Action.
• Move the "updateReviewerStats" function to a server function, triggered by database notification (and other things) rather than a PG function. Makes it much easier to see when it's running
• Made sure "updateReviewerStats" gets called async and send to the Throttle queue, which means it has to wait until the current action sequence is complete, and won't block the UI (as the Action triggers don't wait for it)

Additional related changes

• Make updateReviewerStats callable by command line, so we can run manually on existing applications if desired
• Make Throttle a global object so can be used by more than just the database trigger functions (and update types accordingly)
• Data migration to re-calculate reviewer actions for existing applications (that have reviewer actions currently), as we had a few where they were showing up as "Assignable" even though they were approved.

[^1]: It was running for a single reviewer for each insert, whereas now it runs once for all reviewers. I didn't realise quite how bad it was, due to two things:

• even though it only runs for a single reviewer, the reviewer and assigner lists for the application table were being re-calculated every time, which was very wasteful
• the review_assignment_assigner_join captures a many-to-many relation, so by calling the function on every insert, the number of potential assigners for each application can be quite large (they get repeated for each review assignment, so there was 112 in the case that was making this problem noticeable on the Fiji server). And because a lot of them were self-assigning, it's the same person for a lot of them. So we would be getting well over a hundred calls for what boiled down to about 10 actual users. i.e. if it had only been running once per person, it might have been okay, but once per assigner-assignment join was too much!

[andreievg]

I think it's worth handling an error in action queue: https://github.com/msupply-foundation/conforma-server/compare/1120-fix-trigger-block-for-review-stats-update...1120-fix-trigger-block-for-review-stats-update(Error-handling)

[CarlosNZ]

I think it's worth handling an error in action queue: 1120-fix-trigger-block-for-review-stats-update...1120-fix-trigger-block-for-review-stats-update(Error-handling)

Yeah, good call: 833703de

[CarlosNZ]

Is there a change that updateReviewStatsFromDBEvent will run multiple times for the same DB event ? (like when review_status_history update or review_assignment or application will be updated multiple times in sequence ?)

Not sure why that would happen. Previously there was a bit of a problem with the trigger field being set/updated/reset in quick succession causing multiple executions, hence I've tightened up those triggers (on application and review_assignment) to only respond to particular columns (i.e. NOT the trigger column).

And review_status_history only ever gets inserts, never updates (and only when the status changes).

[CarlosNZ]

Thanks for the review @andreievg 👍🏼