Case mass-update endpoint.

[apognu]

This PR implements an API endpoint to update select case attributes for a large number of cases. So far, the supported actions are:

• Close cases
• Reopen cases
• Assign cases to user
• Change cases' inbox

This is a work in progress. Notably, some heavy optmization must be done form this first draft to avoid hammering the database for all cases in the request.

[Pascal-Delange]

Then there is the nastier question of case update side effects.
Currently those include:

• assign to self (if unassigned)
• unboost (if boosted)
• unsnooze (if snoozed)
• set status to investigating (if pending)

In this context (batch action, most likely from an admin, in any case not by someone who is specifically trying to work on "that one case"), I think there is an argument for doing 2 and 3 but not 1 and 4.

[Pascal-Delange]

Thinking out loud: I think it's correct to make this check in the backend and let the endpoint accept cases from different inboxes, however I think we may want to restrict the action of (re)assigning cases in batch to the "inbox" view, meaning not allow in the "my cases" view, because doing so would create a level of headaches related to selection of eligible users and error handling that is beyond the scope of what we planned to do, cc @ChibiBlasphem

[apognu]

Oh yes, the side effects are on my to-do, pending discussion on what we want to do.

[apognu]

As settled on Slack, for now, the only side effect we want is unboosting the affected cases. This is done.