[GCP] Refactor the reserved instances cache

[Michaelvll]

The previous implementation of GCP's reserved instance cache has different cache for multiple GCP() cloud objects. This can cause long optimization time if multiple resources are specified with different GCP() objects.

This PR refactors the cache out to a module to avoid querying the reservation list multiple times.

It reduces the time for optimization from 13 seconds to 4 seconds for the following yaml:

resources:
    # accelerators: A100:8
    any_of:
      # AWS:
      - region: us-east-1
      - region: us-east-2
      - region: us-west-1
      - region: us-west-2
      # GCP
      - region: us-central1
      - region: us-east1
      - region: us-east4
      - region: us-west1
      - region: us-west2
      - region: us-west3
      - region: us-west4

sky launch -c test test.yaml

Tested (run the relevant ones):

• Code formatting: bash format.sh
• Any manual or new tests for this PR (please specify below)
  • sky launch --cloud gcp -t n2-standard-2 echo hi with reservation for n2-standard-2
  • sky launch -c test-gcp --cloud gcp echo hi on master
  • sky exec test-gcp echo hi on current PR
• All smoke tests: pytest tests/test_smoke.py
• Relevant individual smoke tests: pytest tests/test_smoke.py::test_fill_in_the_name
• Backward compatibility tests: bash tests/backward_comaptibility_tests.sh

[concretevitamin]

Thanks @Michaelvll - LGTM.

[concretevitamin]

May need to test back-compat.

[Michaelvll]

Just tested excuting new job and launching again on existing cluster. It works correctly. Added the tests in the PR description. Thanks!

[concretevitamin]

Any quick test on whether the cache is effective within a process? Asking because the args passed are slightly different than before.

[Michaelvll]

Yes, I added a logging in L104 and tried to remove the decorator. With the decorator the logging will only be shown once, but without the decorator it will show the output multiple times.

Also, tried to change the ttl to 0.3, and it shows the output three times during the optimization.

[concretevitamin]

We may want to add a comment to class Cloud docstr, something like:

Lightweight stateless objects. SkyPilot may create multiple such objects; therefore, subclasses should take care to make methods inexpensive to call, and should not store heavy state. If state needs to be queried from the cloud provider and cached, create a module in sky/clouds/utils/ so they can be reused across cloud object creation.