Move standard library initialization to genesis transactions

[thehowl]

Standard libraries can and should be treated as regular packages; which, at least for the time being, can only be loaded at genesis.

Related discussion: #2319 (comment)

After discussing with Milos, we agreed that it makes sense for the gno.land node at startup to be ignorant about standard libraries; this way, we can further separate the gno.land application binary from needing a surrounding gno repository to work.

To make this work, we'll likely additionally need adequate mechanisms to make stdlib loading fast in testing code and in gnodev, which often restart nodes from genesis. Currently, this is implemented by the method LoadStdlibCached, which is very effective at cutting down start-up costs in these scenarios currently, but would have to be removed if we moved to having stdlibs in the genesis file.

Related #1248

[moul]

The goal is to use a go-embed of the standard libraries and utilize this embedded component while generating the hot genesis in gnodev/gnoland start. At the end, we will be able to manually craft a static genesis when creating the mainnet one.

[n0izn0iz]

Should we create a new message type like MsgAddStdlib or change MsgAddPackage behavior during genesis?

If we just use MsgAddPackage as-is, it will fail while validating the pkgpath which is expected.
To move forward, I disabled the validation if height == 0 here

If I keep this direction (special behavior if height is 0) I will modify the check to only allow normal pkg paths and stdlibs during genesis and not fully disable the check.

WDYT?

[n0izn0iz]

Standard libraries can and should be treated as regular packages

Stdlibs break the promise that a pkgpath uniquely identifies code across all chains, if we do want to treat stdlibs as regular packages then they should probably get a full pkgpath like gno.land/s/std, gno.land/s/unicode/utf16 or gno.land/p/stdlibs/std, gno.land/p/stdlibs/unicode/utf16

[n0izn0iz]

The goal is to use a go-embed of the standard libraries and utilize this embedded component while generating the hot genesis in gnodev/gnoland start. At the end, we will be able to manually craft a static genesis when creating the mainnet one.

I'm realising that using goembed is a much wider scope than injecting stdlibs in genesis txs from the sources and are mostly independent. Which one do you want first?

EDIT: actually it's okay, I had some troubles with the embeds in the TestStore but it's resolved now

[zivkovicmilos]

Should we create a new message type like MsgAddStdlib or change MsgAddPackage behavior during genesis?

If we just use MsgAddPackage as-is, it will fail while validating the pkgpath which is expected. To move forward, I disabled the validation if height == 0 here

If I keep this direction (special behavior if height is 0) I will modify the check to only allow normal pkg paths and stdlibs during genesis and not fully disable the check.

WDYT?

@moul @thehowl

I'm honestly more leaning towards MsgAddStdlib, because it's a much cleaner approach, and doesn't mix the concept of packages and standard libraries.

What do you think about this, we need to unblock @n0izn0iz ?

[thehowl]

Standard libraries are just pure packages, no?

I'm of the opinion we should allow this in the keeper, and allow using any import path at genesis: then restrict to gno.land/{p,r} after genesis.