Initial implementation of reprocessing xia2.multiplex jobs via SynchWeb

[amyjaynethompson]

This PR provides an initial implementation to reprocess xia2.multiplex jobs. In a first instance, it might make sense to limit this feature to reprocessing existing jobs with different command line parameters. This is to keep the bookkeeping in SynchWeb as clear as possible.

This PR introduces a separate trigger function, because much of the main multiplex trigger function is unnecessary for a reprocessing job under this specification.

Examples of features of main trigger functions that don't work in this context:

• loop through all sample groups associated with a DCID (for reprocessing, really only want to do a single sample group)
• trigger every dataset vs at end of sample group (not really a consideration for reprocessing)
• wait for datasets to complete (we know they've completed because it is being reprocessed)
• check for space group compatibility, min number datasets, etc (we know this is fine because it has a parent job)
• find files from xia2-dials jobs (we can get this directly from the parent job)

Instead, an ISPyB query can get the information required based on the parent job.

In SynchWeb, the new job is assigned a new processingJobId in ISPyB, and user defined parameters are given processingJobParameterIds. One of the processingJobParameters is the autoProcScalingId of the original multiplex job. From here, it is straightforward to query the database to find the DCIDs contained in the original job (as well as which sample group, and the data paths included).

This has been tested using ispyb-dev-1 which now has a multiplex reprocessing button. Using this interface submits the parameters to the ISPyB database. A new multiplex recipe is then called with zocalo.go -n -r trigger-multiplex -s ispyb_process=<processingJobId> where the processingJobId is the new job registered by SynchWeb (and linked to the user defined parameters).