[Subnet Prioritization] Support capacity-optimized-prioritized and prioritized Allocation Strategy

[Allenz5]

Description of changes

• Add Priority to subnets when creating fleet using capacity-optimized-prioritized and prioritized Allocation Strategy

Tests

• Extended test_fleet_manager.py::test_fleet_manager.py to test that Priority is appended in overrides when using capacity-optimized-prioritized and prioritized Allocation Strategy

References

• Link to impacted open issues.
• Link to related PRs in other packages (i.e. cookbook, node).
• Link to documentation useful to understand the changes.
• Link to documentation useful to understand the changes.

Checklist

• Make sure you are pointing to the right branch.
• If you're creating a patch for a branch other than develop add the branch name as prefix in the PR title (e.g. [release-3.6]).
• Check all commits' messages are clear, describing what and why vs how.
• Make sure to have added unit tests or integration tests to cover the new/modified code.
• Check if documentation is impacted by this change.

Please review the guidelines for contributing and Pull Request Instructions.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[himani2411]

Update the PR description to mention what is no longer relevant

[gmarciani]

[CodeStyle] We could reduce code duplication by defining the common part of the dictionary just once, then add the priority to it if subnet prioritization is enabled.

[gmarciani]

The change log entry should be more focus on the user experience. Could even simply be "Support new allocation strategies prioritized and capacity-optimized-prioritized to take into account the subnet prioritization on scale out."

[gmarciani]

[CodeStyle] "prioritized", "on-demand", "spot", "capacity-optimized-prioritized" should be defined as constants in an Enum within a common script (see how we did it in cli package: https://github.com/aws/aws-parallelcluster/blob/develop/cli/src/pcluster/config/common.py#L31-L36).

This is a good way to use the code as a way to document supported values, prevent constants to be redefined and potential errors caused by typos.

[gmarciani]

[Tests] We are introducing a new function. We are testing it as part of the unit tests for the upper level function _evaluate_template_overrides. However, we should always add a specific unit test for every new function and mock its behavior in unit tests for the upper level one. In this way it's easier to decouple behavior and address defects in case of failures.