Add meta during stellar contract build

[leighmcculloch]

What problem does your feature solve?

Build tooling, CI environments, and other things outside the code want to conveniently add meta data to the contract as part of the build process.

The main use case is to support setting meta during a verified build process that @orbitlens is building.

What would you like to see?

A new option on the stellar contract build command that includes additional metadata to be written into the contractmetav0 custom section as SCMetaEntry XDR entities.

stellar contract build --meta key1=val1 --meta key2=val2 ...

What alternatives are there?

Contract can already embed meta in themselves by making the following call in the code:

soroban_sdk::contractmeta!(key = "...", val = "...");

However, sometimes build systems would like to add meta information, such as the source code repo the build is occurring from, or the commit being built, and that information may not be accessible to the code to insert itself.

It may be possible to structure that stuff with a build.rs script, but adding the ability to pass meta at the tooling level means that contracts don't need to write any code for build tooling to augment the meta.

Thanks

This idea was shared by and requested by @orbitlens in Discord:

• https://discord.com/channels/897514728459468821/1218934322745315389/1285154853752012852

cc @janewang

[leighmcculloch]

This may be somewhat tricky, we need to introduce a WASM parser and generator to the CLI. We'll have to parse the WASM, get out the existing custom section, then rewrite the rest of the file back without that section, and then append a new section with the additional data.

Today we only do appending to WASM files, and parsing, we don't delete sections. I don't think the crates we're currently support deleting, so we'll need to look around and assess what's reliable. Anything we add to the main build command must be reliable so let's take care with that.

[leighmcculloch]

@elizabethengelman Rereading the wasm spec on custom sections, it is allowable for multiple custom sections to exist with the same name, and so the safest and simplest option may be for the additional meta entries to be written to a new custom section that has the same name contractmetav0.

We'd just need to update tooling to read from all custom sections with that name, instead of only reading from the first.

This would eliminate the need for us to find new wasm writing dependencies that involve rewriting the whole file.

[elizabethengelman]

@leighmcculloch Thanks for that update - that seems like it would be a safer and easier way to handle this.