smoldot support in codegen

[tjjfvi]

moved from #455 (comment)

I think we should separate the discovery value used for the codegen from the discovery value used at runtime. Right now they're linked, but theoretically it shouldn't matter if, say, a proxy server is used for the codegen but then smoldot is used at runtime, as the codegen only cares about the metadata, as AFAIK that is independent of the way you connect to the chain.

I think it's much more important to support using smoldot at runtime by divorcing the codegen discovery value from the runtime discovery value than by supporting smoldot for the codegen discovery value (although that will, of course, be important). Right now, I don't think there's a great way to do this, but I think this will be feasible upon the integration of env into Rune.

In terms of supporting smoldot for the codegen discovery value: As those who have concern about using proxy servers would likely have similar concerns about using capi.dev, we could, if useful, only support smoldot codegen on the local server, which would allow us to, say, rely on some config passed in via command line to specify the chain spec. For example, the url could just be something like /smoldot/polkadot, and the server could have config mapping polkadot to an appropriately up-to-date chain spec. This way, the URLs are stable, and don't have to change as the chain spec evolves. (Although, given the stability & caching of the codegen, I suspect that the chain spec would not need to be updated all that often for the codegen, though I may be mistaken.)

This would mean:

• people using capi.dev would use a proxy server for the codegen (which, I'll note, greatly aids the readability of the URLs), but would be free to (and, no doubt, encouraged to) use smoldot at runtime
• those running their own server would have the additional option of using smoldot for the codegen, albeit at the price of some extra configuration
  • if we wanted to ease this transition, we could additionally support in the config mapping an alias like polkadot to either to a proxy endpoint or a chain spec, so that people could easily switch at any time

[harrysolovay]

Blocked by #517

[harrysolovay]

Given that we won't want to support Smoldot as a means of fetching info for codegen. As @tjjfvi mentioned, the path is that of #621 + using DI (#517) to inject the actual Smoldot connection at runtime.

[tjjfvi]

Agreed, although I suspect most often we wouldn't use the bytes provider of #621 but rather use the proxy provider.