Split DM_Workflow from acquisition routines

[qzhang234]

@prjemian I would like to propose the following change to the Bluesky definition at 8-ID-I:

1. Create a file in /device called APS_DM_8IDI_QZ.py;
2. Copy everything from /spec_support/APS_DM_8IDI.py (the file that defines class DM_Workflow, in particular all the class methods that start DM_Workflow from command lines;
3. Append class DM_Workflow with all atrributes from class DataManagementMetadata in /device/datamanagement/;
4. Import DM_Workflow class in the Rigaku ZDT testing code, kick off the DM Workflow inside the acquisition for loop, add a try-except that unconditionally ignore ANY errors that may arise from inside the DM Workflow part.

[prjemian]

Let's discuss in our meeting this afternoon.

[qzhang234]

Of course. These are notes to facilitate the discussion. Thought I would write it down to organize my thoughts

[qzhang234]

Per discussion with @prjemian, The proposed change is not necessary. DM is defined independently from AD_Acquire and can be called separately, all that is needed is to add the lines in the original Rigaku test code to start the workflow

The idea of creating the Run_Object class that takes in both dm_pars, dm_workflow and user/sample info is discussed, but since the current DM structure is shared between Spec and Bluesky, it's better to postpone the code consolidation until 8-ID is running 100% Bluesky

[qzhang234]

Closing this issue for now as it is of lower priority at this moment. Will reopen if necessary.