VMXm BlueAPI gridscan testing notes

I got as far as trying to stage zocalo before stopping for the day. There is enough here to keep us busy though...

- Need to create our own container to install `mx-bluesky` dependencies, see https://github.com/DiamondLightSource/mx-bluesky/issues/922
- Container doesn't have permission to write to mx-bluesky default log directory (and it's not mounted)
- Container doesn't can't see daq configuration - I think this is only a problem for `DetDistToBeamXY`
- Need a proper GDA change to get VMXm to call BlueAPI with correct parameters - see `blueapi-fgs-testing` branch on VMXm's GDA for my hacky change
- GDA still has the BlueAPI URL hardcoded in java file - it will be set to a property in https://gerrit.diamond.ac.uk/c/gda/gda-core/+/43523
- Container doesn't have the mounting or permissions for snapshots.
- ArgoCD keeps switching itself back to 'autosync' which is fine for now but maybe dangerous in production
- Container doesn't have correct mounting to read ISPyB config, and doesn't have permission to read the file even if it is mounted
- Container doesn't have correct mounting to read zocalo config yaml
- VMXm don't scan their sample to ispyb in the same way as i03, so their sample id is None. Our parameters enforces it to be an integer.
- Fast grid scan common plan requires a smargon device - but it doesn't need to. We need to loosen the requirements here, I think only the `omega` motor is used in the plan, so perhaps it can just require any device with an `omega` motor