Deprecate Trainer.devices in favor of Trainer.num_devices and Trainer.device_ids

[DuYicong515]

What does this PR do?

Part of #12171

Does your PR introduce any breaking changes? If yes, please list them.

N/A

Before submitting

• Was this discussed/approved via a GitHub issue? (not for typos and docs)
• Did you read the contributor guideline, Pull Request section?
• Did you make sure your PR does only one thing, instead of bundling different changes together?
• Did you make sure to update the documentation with your changes? (if necessary)
• Did you write any new necessary tests? (not for typos and docs)
• Did you verify new and existing tests pass locally with your changes?
• Did you list all the breaking changes introduced by this pull request?
• Did you update the CHANGELOG? (not for typos, docs, test updates, or internal minor changes/refactorings)

PR review

Anyone in the community is welcome to review the PR.
Before you start reviewing make sure you have read Review guidelines. In short, see the following bullet-list:

• Is this pull request ready for review? (if not, please submit in draft mode)
• Check that all items from Before submitting are resolved
• Make sure the title is self-explanatory and the description concisely explains the PR
• Add labels and milestones (and optionally projects) to the PR so it can be classified

cc @four4fish @awaelchli

[ethanwharris]

LGTM, small comment

[awaelchli]

Apologies for the delayed review.

[awaelchli]

I would have preferred if this was implemented on the accelerator connector. It is IMO not the responsibility of the Trainer to compute the device_ids off the strategy. Note the the strategy is owned by the connector, not the trainer. As the trainer has already many responsibilities, we should delegate as much as possible to the concrete components.

[DuYicong515]

Thanks for reviewing @awaelchli!

My personal thoughts: the accelerator connector should stay internal, and accelerator connector should not expose those device related public properties.

Note the the strategy is owned by the connector, not the trainer.

Personally I feel the accelerator connector does a lot of checks/set up/initialization and configuration of the accelerator and strategy. After things are set up already, strategy/accelerator are already accessible on the Trainer, while the connector stays internal.

I think delegating computations using accelerator/strategy to the accelerator_connector will make us add many public properties to the internal-facing accelerator_connector. Deriving from strategy/accelerator directly are more straight forward, and they(strategy, accelerator) are very external facing as well.

I'm very new to this and my feelings might be wrong. Feel free to add more thoughts to issue #12171!