Add Ngen Calibration Request Variant

[aaraney]

Add support for Ngen Calibration Requests. This request type is identical to NGENRequest's with the caveat of the model_name field which is now ngen_cal instead of ngen.

The schedule has been updated to handle the NGENCalibrationRequest variant. NGENCalibrationRequests, for now, use the container image tag pair of 127.0.0.1:5000/ngen_cal:latest.

Additions

• Add support for Ngen Calibration Requests.
• Scheduler supports Ngen Calibration Requests. Expects container image tag pair 127.0.0.1:5000/ngen_cal:latest to handle these requests.

Changes

• Search for valid ModelExecRequest subtypes is now recursive.

Todos

• Determine requirements and implement a NGENCalibrationRequestResponse variant.
• Create ngen_cal Dockerfile.
• bump communication and scheduler minor versions.

Checklist

• PR has an informative and human-readable title
• Changes are limited to a single goal (no scope creep)
• Code can be automatically merged (no conflicts)
• Code follows project standards (link if applicable)
• Passes all existing automated tests
• Any change in functionality is tested
• New functions are documented (with a description, list of inputs, and expected output)
• Placeholder code is flagged / future todos are captured in comments
• Visually tested in supported browsers and devices (see checklist below 👇)
• Project documentation has been updated (including the "Unreleased" section of the CHANGELOG)
• Reviewers requested with the Reviewers tool ➡️

[aaraney]

The failing test is coming from the evaluations package (TypeError: <class 'pint.util.Quantity'> is not a generic class). #184 should resolve this issue.

[robertbartel]

@aaraney, take a look at this branch in my fork. I have done a bit more with a calibration message implementation (also created a response type for it) and build handlers under the dmod.externalrequests library. I've also updated the request service for it. I hadn't gotten to what you've done for the scheduler or written any tests, through, which are important. I.e., we probably want to combine these.

[aaraney]

@aaraney, take a look at this branch in my fork. I have done a bit more with a calibration message implementation (also created a response type for it) and build handlers under the dmod.externalrequests library. I've also updated the request service for it. I hadn't gotten to what you've done for the scheduler or written any tests, through, which are important. I.e., we probably want to combine these.

Thanks for pointing me in this direction. It looks like you've handled a lot pieces that i'd not considered yet and will eventually be relevant to something like the dataservice (i.e. defining and differentiating calibration configuration files). With that in mind and this PR contributions to the scheduler service, does it makes sense to rebase my scheduler changes onto your branch and open a PR to pull them into your branch and then you can open a PR to pull all of this work into master?

While looking through your branch, I think you may need to update get_available_models() to recurse on subclasses. Right now it will only return direct descendant subclasses of ModelExecRequest, meaning I don't think an NgenCalibrationRequest instance could be created by ModelExecRequest.factory_init_correct_subtype_from_deserialized_json(cls, json_obj: dict).

[robertbartel]

Closing; consolidating these and other changes in #240.