[integ-tests-framework] Make capacity reservations for all instance types

[hanwen-cluster]

Description of changes

1. With [integ-tests] Improve test_proxy to avoid insufficient capacity error #7440, we started to make capacity reservations for {"c5.xlarge", "m6g.xlarge", "m6i.xlarge"}, and use other similar instance types if a capacity reservation fails to creat. This commit expands the logic to all instance types.
   1.1. With instance types <= .xlarge, we make duplicate capacity reservations because multiple tests in parallel could use the same instance types, therefore need multiple capacity reservations. With instance types >.xlarge, we make only one capacity reservation because tests with larger instance types usually make capacity reservations early in the test definition (e.g. test_efa in commercial makes capacity reservation in develop.yaml), therefore this second layer of capacity reservation shouldn't make duplicate capacity reservations.
   1.2. With instance types supporting EFA, create the capacity reservation in a placement group. With instance types not supporting EFA, create the capacity reservation without a placement group.
2. With this commit, resolve_instance_with_capacity allows specifying alternative_instance_types. Prior to this commit alternative_instance_types was always calculated with get_similar_instance_types, which could be too restrictive, so don't give too many alternatives for instance types like c5n.18xlarge
3. Improve test_efa in isolated_regions to take a flag to use any efa instances to avoid Insufficient Capacity Error. test_efa in commercial doesn't need this, because it could try out different regions. In isolated regions, the test has to run in a specific region.

Tests

test-suites:
  efa:
    test_efa.py::test_efa:
      dimensions:
        - regions: ["ap-southeast-5"]
          instances: ["c5n.18xlarge"]
          oss: ["alinux2023"]
          schedulers: ["slurm"]
          flags: ["any-efa-instances"]
        - regions: ["us-east-1"]
          instances: ["c5n.18xlarge"]
          oss: ["alinux2023"]
          schedulers: ["slurm"]

In the above tests, the test in us-east-1 passed completely. The test in ap-southeast-5 failed some checks in fabtest because it was using g6.8xlarge. This failure is not a regression from this PR, and won't surface in isolated regions because fabtest is not run in isolated regions.

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.

[hehe7318]

[Blocking] Should we also check the CapacityResevations available capacity? Or is it handled in other place?

[hanwen-cluster]

This second layer of capacity reservation doesn't have visibility into how many instances are required by a test. So we just check a capacity reservation exists and don't care about the available capacity. If a test is peculiar on the available capacity, it should make explicit capacity reservation in develop.yaml

[hehe7318]

If multiple tests run in parallel using the same ODCR, is there a risk of consuming all capacity and causing an ICE error?

[hehe7318]

Where do we cleanup these PlacementGroup?

[hanwen-cluster]

We don't clean up. Since the naming of the placement groups is {instance_type}_placement_group_{az_id}, we won't create too many even without cleaning up. AWS limits 500 placement groups per region, which is safe for us

[hehe7318]

Okay, makes sense, so these PlacementGroup are long live, and can avoid re-creating everytime.