Run smoldot in the content script instead of the extension

[tomaka]

This issue covers one option that we could go for in order to fix #549

As the title says, the basic idea is to run smoldot in the content script of each individual web page rather than in the extension.
The extension would only be used as a "coordinator" between all these instances.

The design is a bit complicated, but it would work like this:

• When the extension starts, it starts its own instance of smoldot with the four well-known chains, and once these four chains are synced their database is extracted and stored in the local storage. It might be that this instance gets killed before it has managed to sync, but that's only an optimization so it's ok.
• When needed, the content script starts an instance of smoldot, and reports this to the extension. The extension assigns an id to this content script. It then sends back the ids of all the other existing content scripts that have a smoldot instance, and notifies all the other content scripts that have a smoldot instance about this new id. For better debuggability, this id could include parts of the URL of the page with the content script, but of course this must be done carefully.
• When the extension reports to a content script that another instance exists, the content script injects in smoldot the id of the other or all the other content scripts that have an instance of smoldot. This is done by using /memory multiaddresses (for example: /memory/1) and the sudo_unstable_p2pDiscover JSON-RPC call.
  • Should smoldot refuse sudo_unstable_p2pDiscover JSON-RPC requests that contain a /memory address that don't come from the extension? It can't be used as an attack vector, but we could do it anyway just in case.
• When smoldot tries to connect to a /memory/xxx address, we send a message to the extension which either accepts or refuses the connection depending on whether the content script with that id is still alive.
  • After a connection to a /memory/xxx address has been established, when smoldot sends a message to that connection, it is sent the extension, which in turn sends the message to the proper content script.
  • If a content script gets killed, the extension notifies the other smoldot instances of the connection closure.
• When smoldot tries to connect to a non-/memory address, the content script first asks the extension for the authorization to connect. The extension can say yes or no. The actual connection is still done in the content script. The extension limits all the smoldots combined to 3 external connections maximum. Any further will be refused.
  • Note that it may look like the extension should notify the smoldot instances when a connection has been closed, in order for the same or another smoldot to take the relay. However, when a connection is closed, either the smoldot that had the connection will try to connect to a different node, or it's because the smoldot that had the connection has been killed in which case the other smoldots will lose a peer and try to connect to a different node. In other words, it's a non-issue but should be documented nonetheless.
• Should every smoldot instance connect to all the well-known chains at initialization? Unclear. Not doing it means that if the user calls addChain with for example the Polkadot chain spec, the smoldot instance won't benefit from the existing Polkadot database nor the bootnodes configured in the extension. But this might be a desirable behavior.
• When a smoldot instance wants to connect to a well-known chain, it downloads the list of bootnodes and the database from the extension. This is done by sending a message to the extension and waiting for the response to come back.
• TODO: need a way for the extension to update its database of the smoldots that are running, but this requires knowing which smoldot is the most ahead ; I don't think it's complicated but it's unclear whether to use a push or a pull based model for this, and it's not important to decide this at the moment

This also requires some changes in smoldot:

• Make the wasm node announce blocks to the nodes it is connected to smoldot#2157
• Implement /memory multiaddresses smoldot#2158
• Make the wasm node announce participate in transactions gossip smoldot#2225
• Implementing answer block, warp sync, and storage requests from the light client smoldot#2224
• Trusted light clients system smoldot#2223

The extension would still be able to know and display the list of websites and which chains they're connected to, so the UI doesn't need to change.
Because there's no risk anymore for a website to crash or overload the extension, we can remove the "ban website" feature.

[tomaka]

I think we should not wait for WebRTC anymore and just work on this.

[tomaka]

The important point that remains to do is to run smoldot at extension initialization to populate databases.

[wirednkod]

The important point that remains to do is to run smoldot at extension initialization to populate databases.

Opened #1297

[wirednkod]

This is done so can be closed