Orchestrator: convert to class implementation (issue 167)

[rlxdev]

🗣 Description

I converted the orchestrator module to a class. My aim when refactoring this module was to minimize the changes to the original code, while converting the individual functions to methods of the Orchestrator class. I kept the use of args from the parsed command line arguments, rather than try to separate out the nearly 20 arguments into instance variables. This helps to keep the structure of the code the same.

If you compare this class implementation with the non-class module, while ignoring
whitespace and empty lines, there are only 37 differences.

💭 Motivation and context

closes #167

🧪 Testing

I've tested these changes by running several different variations of ScubaGoggles runs. With minimal changes made to the code, I've got a high confidence that the class works correctly, as it did when the orchestrator was implemented as separate functions in the module.

✅ Pre-approval checklist

• This PR has an informative and human-readable title.
• Changes are limited to a single goal - eschew scope creep!
• If applicable, All future TODOs are captured in issues, which are referenced in the PR description.
• The relevant issues PR resolves are linked preferably via closing keywords.
• All relevant type-of-change labels have been added.
• I have read and agree to the CONTRIBUTING.md document.
• These code changes follow cisagov code standards.
• All relevant repo and/or project documentation has been updated to reflect the changes in this PR.
• Tests have been added and/or modified to cover the changes in this PR.
• All new and existing tests pass.

✅ Pre-merge Checklist

• This PR has been smoke tested to ensure main is in a functional state when this PR is merged.
• Squash all commits into one PR level commit using the Squash and merge button.

✅ Post-merge Checklist

• Delete the branch to clean up.
• Close issues resolved by this PR if the closing keywords did not activate.

[LaurenBassett]

This looks good to me, but I'm having some import errors. I think it's my machine though. I'll keep troubleshooting. Just wanted to comment to say I've started reviewing.

[LaurenBassett]

For documentation's sake, I'm getting one of two errors depending on if I run the code in the virtual environment or locally.

In the virtual environment:
ValueError: numpy.dtype size changed, may indicate binary incompatibility. Expected 96 from C header, got 88 from PyObject

Which tells me it doesn't like the version of numpy I'm using

Update: I was able to fix this by downgrading the version of numpy used.

pip install numpy==1.26.4

---

Locally:
ImportError: cannot import name 'Enum' from partially initialized module 'enum' (most likely due to a circular import) (/Library/Frameworks/Python.framework/Versions/3.12/lib/python3.12/enum.py)

Which tells me there's some circular import with the Enum package I think.

I think the issue is with my python installation, but want to capture this in case anyone else runs into it.

[LaurenBassett]

Looks great to me. Not sure what's going on with the numpy package, and if it is a me problem or an everyone problem, so it may be worth looking into, but other than that it looks great! :-)