LightClient: Optimize multi-chain usecase

[lexnv]

Subxt spawns a background task for handling communication with the lightclient (smoldot).

Currently, users who want to target multiple chains must construct one smoldot instance per chain.
This leads to spawning and handling multiple background tasks.

To optimize this process, subxt could reuse the same background task to handle multi chains.
Investigate if this is feasible without breaking changes in the subxt-API; and extend the communication protocol to support the AddChain command.

[jsdw]

I'd be interested to know what advantages this offers over having a separate Smoldot instance per chain (@tomaka, do you have any thoughts here; is it better to one one Smoldot instance for several chains or separate instances per chain?).

But yup, assuming that using one instance can be advantageous,it'd be nice if we could configure some LightClientInstance separately and then can clone it and call some function to construct a LightClient's from each clone that's targeting a specific chain.

[tomaka]

A smoldot Client is basically a glorified Vec<Chain> except that it will share some resources between chains when possible. For example, the same networking connection might be used to talk to the same peer through two different chains.
There's no reason to use one client per chain.

[jsdw]

Ok, thanks! Right now, we use one Smoldot client per chain just because it was the simplest thing to add, but if the resource sharing is meaningful then it does make sense to add the ability to share one Smoldot client for accessing several chains.