Multiple concurrent gRPC subscriptions

I am struggling to work out how to subscribe to multiple streams of information. In my case that I am testing with at the moment, I want to subscribe to multiple bits of BGP information across multiple devices and react to changes.

Devices:
``path_elements = ["DatasetInfo", "Devices"]``

Then for each device it's BGP VRFS:
``path_elements = ["Devices", , "versioned-data", "routing", "bgp", "status", "vrf"]``

Then for each device VRF, it's BGP Peers:
``path_elements = ["Devices", , "versioned-data", "routing", "bgp", "status", "vrf", , "bgpPeerInfoStatusEntry"]``

My script then reacts to event changes in the BGP peer states, and also adds or removed devices VRFs and peers as the updates come in. It almost works beautifully, but...

Because the ``grpc_client.subscribe(query)`` never returns, I initially ran it in a thread. This works for a few devices, VRFs and Peers, but is not very scalable. Once I got to 129 threads, I could not run any more. I tried using asyncio, but it appears while grpcio is supposed to support asyncio the cloudvision module does not. The examples as far as I can see only have very simplistic subscribe models. For example, the get_if_rate.py only gets a single metric from a single interface.

```
with GRPCClient(apiserverAddr, token=token, certs=cert, key=key,
ca=ca) as client:
for batch in client.subscribe(query):
for notif in batch["notifications"]:
pretty_print(notif["updates"])
```

I can't see a good way to deal with subscriptions in a scalable way using the cloudvision module. can someone please clarify how this should be done. It would be good if this can also be reflected in the Docs or examples. If it is already in there, and I am blind or stupid, can someone please point me in the right direction.

Start with the get_if_rate.py example and the GRPCClient.subscribe(query) entry point described in the issue. Investigate how multiple device, VRF, and peer streams could be handled without one thread per subscription, including the reported asyncio limitation. Done means the supported scalable approach is clarified in the documentation or a new example.

Written by the indexing model from the issue text.