[Feature Request] Distributed data collectors

Current state of data collectors

We currently have parallel data collectors, that can handle a single or multiple environments running serially or in parallel.
Say one has access to N cpus to run an experiment. She has 3 different choices:

• Create a single collector and N envs in a ParallelEnv wrapper. A rollout then looks like

for t in range(n_steps):
    tensordict = policy(tensordict)  # policy is run over the previous N outputs
    tensordict = env.step(tensordict)  # there are N envs in env
    out.append(tensordict)
return out

• Create X = N // Y parallel envs on Y collectors. Each of the Y collectors runs its own loop:

for t in range(n_steps):
    tensordict = policy(tensordict)  # policy is run over the previous X outputs
    tensordict = env.step(tensordict)  # there are X envs in env
    out.append(tensordict)
return out

The advantage is that we can run things asynchroneously, and get the results of the collector that finished first, while still benefiting from ParallelEnv and running the policy on CUDA over more than one input.

• Create a set of N collectors, each containing a single environment.

Feature description

We'd like to be able to create distributed data collectors over multiple nodes. Ideally, creating a distributed data collector should not be much harder than creating a multiprocess one. The inputs to pass to this data collector for construction are the following:

• A list of environment creation functions: this may not be easy to pass from node to node. Perhaps CloudpickleWrapper could handle that? Otherwise we'd need to pass a set of instructions to the node on how to build the environment, which can be tedious in some instance and would require us to think carefully about the API.
• Collection parameters: total number of frames to collect, frames per batch, whether we should start with random policy, etc.
• Device on which the policy should be placed and device on which the data will be placed before it's sent to the main worker
• It would be also nice to pass env variables for the distant node

Passing data:
On AWS clusters, it sometimes happens that those nodes can use a common physical memory system (fsx) where shared tensord can be stored. We already have MemmapTensors in torchrl to handle this use case and pass data efficiently from node to node.

cc @H-Huang for suggestions