Add ContractArgs for building function args

[leighmcculloch]

What

Add ContractArgs for building function args.

Usage

-let contract_id = env.register(Contract, (100_u32, 1000_i64));
+let contract_id = env.register(Contract, ContractArgs::__constructor(&100_u32, &1000_i64));

Diff of generated code for constructor test vector

@@ -7,6 +7,8 @@ extern crate core;
 extern crate compiler_builtins as _;
 use soroban_sdk::{contract, contractimpl, contracttype, Env};
 pub struct Contract;
+///ContractArgs is a type for building arg lists for functions defined in "Contract".
+pub struct ContractArgs;
 ///ContractClient is a client for calling the contract defined in "Contract".
 pub struct ContractClient<'a> {
     pub env: soroban_sdk::Env,
@@ -210,6 +212,17 @@ impl<'a> ContractClient<'a> {
         res
     }
 }
+impl ContractArgs {
+    pub fn __constructor<'i>(
+        init_key: &'i u32,
+        init_value: &'i i64,
+    ) -> (&'i u32, &'i i64) {
+        (init_key, init_value)
+    }
+    pub fn get_data<'i>(key: &'i DataKey) -> (&'i DataKey,) {
+        (key,)
+    }
+}
 #[doc(hidden)]
 pub mod ____constructor {
     use super::*;

Why

To provide a way to make specifying args as concrete.

Dependent on:

• Fill gaps in ref conversions to Val rs-soroban-env#1479

Close #1348

Note

This is still very much an experiment.

[dmkozh]

I think this is reasonable. I'm not sure it's too useful outside of constructor args, but in general seems ok to have. It also sort of helps with discoverability, as we can advertise this in all the constructor examples.
The only concern is the wasm size - are we sure the args won't bloat the builds in case if they're not used (but the clients are)?

[leighmcculloch]

The only concern is the wasm size - are we sure the args won't bloat the builds in case if they're not used (but the clients are)?

The tests I ran building for wasm before and after this change resulted in no size change to any of the test vectors. Even when used the new code should be entirely inlined and disappear because it's just data pushing. To reduce the chance we're ever wrong about that I just pushed marking the functions as #[inline(always)].

I should add a test vector that deploys a contract, and uses it, and check that for the deploy case it's also a zero cost or near zero cost construct. I'll do that before marking this ready.

[leighmcculloch]

@dmkozh This is ready for review in conjunction with:

• Fill gaps in ref conversions to Val rs-soroban-env#1479