feat: Schedule host-base actions within the VMR schedules

[sdelliot]

feat: Schedule host-base actions within the VMR schedules

Description

Some experiments require additional external input while being conducted. In particular, it would be useful to execute minimega-based actions (adding a new network tap or taking a screenshot or replaying captured VNC) in the context of an existing FIREWHEEL experiment. Currently, this is a manual process where a user has to run these actions separately from the experiment and they cannot be automated as part of the experiment schedule. This new feature addresses this shortcoming.

We introduce the concept of host-based VM resources, where users can, in the context of a single VM's schedule, execute actions on the physical host on which the VM is running. With this change, users can fully take advantage of Minimega's capabilities in the context of a FIREWHEEL experiment. For example, if a user would like to hotplug a USB device, that can now be scheduled via the new schedule entry on_host attribute. This attribute enables the VM Resource Handler to execute subprocess with either minimega specific CLI arguments or with an alternative executable.

This new feature is powerful and could effect experiment repeatability between FIREWHEEL deployments if users do not account for host OS differences. Additionally, there could be security implications for running host-based VMRs from un-trusted experiments. We attempt to mitigate these issues by forcing users to do one of the following:

1. Use minimega as the executable (which should be used for minimega-specific commands).
2. Provide the absolute path to the binary.
3. Provide the relative path to the binary if and only if the binary is a VM resource which is stored in the VMR system.

While these mitigations to not resolve all user obligations, FIREWHEEL developers will also be thoughtful with how this interface is exposed within the base_objects model component (the corresponding PR is: sandialabs/firewheel_repo_base#6)

Type of Change

Please select the type of change your pull request introduces:

• Bugfix
• New feature
• Documentation update
• Other (please describe):

Checklist

• This PR conforms to the process detailed in the Contributing Guide.
• I have included no proprietary/sensitive information in my code.
• I have performed a self-review of my code.
• I have commented my code, particularly in hard-to-understand areas.
• I have made corresponding changes to the documentation.
• My changes generate no new warnings.
• I have tested my code.

[mitchnegus]

I'm good with this at this point. It looks to me like it will still require one last review by @gregjacobus