1/n Simplify spawn plugins: Simplify handling of multiprocessing queue

[awaelchli]

What does this PR do?

Part of #10059, implements the first 3 steps which are highly coupled. Please read steps 1-3 on the issue to better follow the thought process behind this PR. Steps 1-3 are combined in this PR because they are tightly entangled. Steps 4 and 5 will be independent follow-ups.

Notes to reviewer:

• TPUSpawnPlugin subclasses from DDPSpawnPlugin and it is therefore not very feasible to split this PR into two pieces. Due to the inheritance, it makes the most sense to update both plugins in the same PR.
• Please have a look at Deprecate and redefine add_to_queue/get_from_queue in spawn plugins #10865 if you find the time.

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

A very tiny edge case breaking change in two hooks, LightningModule.add_to_queue and LightningModule.get_from_queue which now accept a _SimpleQueue as input instead of a torch.multiprocessing.SimpleQueue. This is however not expected to make an impact directly, since only the type hint changes while the user interface remains exactly the same.

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)
  No new tests are required. We have enough (quite expensive) ddp spawn tests that will pass and confirm that these refactors and redesigns retain the existing functionality and performance.
• Did you verify new and existing tests pass locally with your changes?
• Did you update the CHANGELOG? (not for typos, docs, test updates, or internal minor changes/refactorings)

PR review

Anyone in the community is free to review the PR once the tests have passed.
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

Did you have fun?

I made sure I had fun coding 🙃

Part of #1 (it's a lie, this is just here to avoid noisy GitHub bot)

cc @Borda @justusschock @awaelchli @akihironitta @tchaton @kaushikb11

[carmocca]

Nice!

[four4fish]

This is super cool!! love it!

[tchaton]

Looks great! Awesome work.

[justusschock]

LGTM. Just one minor comment :)

[justusschock]

afaik subclassing mutable builtins (especially dict and list) can sometimes lead to unexpected results. Maybe use UserList as base class instead?

[awaelchli]

got it!

[carmocca]

@justusschock I don't think that's true nowadays: https://stackoverflow.com/questions/25464647/list-vs-userlist-and-dict-vs-userdict

list is the recommended approach for simple extension
and collections.* for complex extension

[carmocca]

Quoting Raymond Hettinger (Python core dev):

"FWIW, the UserDict class in Py3.x was relocated to the collections
module. It isn't gone. We made an effort to kill it but found that
there were compelling use cases that were not a cleanly solved by any
other approach."

https://bugs.python.org/issue5402

[codecov]

Codecov Report

Merging #10034 (2579247) into master (9beeabb) will increase coverage by 0%.
The diff coverage is 77%.

@@           Coverage Diff           @@
##           master   #10034   +/-   ##
=======================================
  Coverage      92%      92%           
=======================================
  Files         177      177           
  Lines       16554    16562    +8     
=======================================
+ Hits        15192    15204   +12     
+ Misses       1362     1358    -4