internal/integration: update the soroban tests for auth next support

[sreuland]

PR Checklist

PR Structure

• This PR has reasonably narrow scope (if not, break it down into smaller PRs).
• This PR avoids mixing refactoring changes with feature changes (split into two PRs
  otherwise).
• This PR's title starts with name of package that is most changed in the PR, ex.
  services/friendbot, or all or doc if the changes are broad or impact many
  packages.

Thoroughness

• This PR adds tests for the most critical parts of the new functionality or fixes.
• I've updated any docs (developer docs, .md
  files, etc... affected by this change). Take a look in the docs folder for a given service,
  like this one.

Release planning

• I've updated the relevant CHANGELOG (here for Horizon) if
  needed with deprecations, added features, breaking changes, and DB schema changes.
• I've decided if this PR requires a new major/minor version according to
  semver, or if it's mainly a patch change. The PR is targeted at the next
  release branch if it's not a patch change.

What

recompiled the wasms with latest upcoming version of rs-soroban-sdk which includes the auth next.
moved the contract source code for test fixtures into integration tests as well for full control.

Why

the soroban contract tests won't work until they are recompiled with wasm that is compliant with latest that core expects for auth next invocations.

Closes: #4757

Known limitations

[sreuland]

contract fn invoke tests are failing at present, much of lower stack is changing atm, env/sdk, need to update the contract test fixtures here to ref the latest rs-soroban-sdk version and also pull the new soroban core with same rs-soroban-env for integration tests to run.

[tamirms]

I think this can be automated using go generate and go embed. Checkout https://github.com/stellar/starbridge/pull/102/files#diff-e27b4787f7b159227c12040f2ed88c1010e737e596b05418831f0b42c4d8243e (specifically, gen.go ). You can add a go file in this directory with the following contents:

package contracts

import _ "embed"

//go:generate sh -c "cargo build --target wasm32-unknown-unknown --release"

//go:embed target/wasm32-unknown-unknown/release/add_u64.wasm
var AddU64Wasm []byte

This way all the contract code will be built via the go generate command (which we already run to generate xdr in the repo).

[2opremio]

I don't think that will work because AFAIC you cannot embed files in parent directories (and the current directory for go:embed is the source file's directory)

golang/go#46056

[tamirms]

the target folder containing the wasm is a child directory of the contracts directory

[sreuland]

@tamirms @2opremio , do we want to start pulling this type of soroban dependency into horizon, the build environment will need to have rust toolchain, we'll need to track down build pipelines on horizon, there's jenkins pipeline builder, and quickstart have builders that would need to update.

I think in the short term of release prep, I could look into something like a dockerfile, which dev can manually run to automate the steps to some degree, does the rust toolchain and cargo builds internally and copy the wasm's to the /testdata/ destination.

can do more enhanced approach such as gogenerate and change the external builder integrations if needed as follow-on tech debt?

[2opremio]

Related: #4760

We should probably incorporate a test making use of auth-next

[sreuland]

@2opremio , as part of footprint processing in sac_test.go, add_footprint(), it's submitting preflight to core's endpoint first and getting errors:

Messages:   	HostError
        	            	Value: Status(UnknownError(0))
        	            	
        	            	Debug events (newest first):
        	            	   0: "wrong number of args"

should that be happening still or has preflight check been changed to use a new endpoint on rpc instead?

[2opremio]

@sreuland uhm, I am not sure what’s broken. I can take a look today.

However, note that AFAIU Core’s simulate transaction endpoint is going away, so we will need to replace it with soroban rpc at some point.

[2opremio]

@sreuland the error is coming from changes in the token contract (which the tests aren't yet accounting for).

See stellar/rs-soroban-env@fc611e5#diff-762cdd179f5c2d24d87ffe8aec8070d12ecdfaf53af56c19d07dfdcaf77bdc29

For instance, mint() has changed from:

fn mint(
        e: &Host,
        admin: Signature,
        nonce: i128,
        to: Identifier,
        amount: i128,
    ) -> Result<(), HostError>;

to

fn mint(e: &Host, admin: Address, to: Address, amount: i128) -> Result<(), HostError>;

Note that it now has 3 arguments.

[2opremio]

I started converting the arguments but I am not sure how to create an Address (I left a TODO), I will ask on Slack

[sreuland]

I started converting the arguments but I am not sure how to create an Address (I left a TODO), I will ask on Slack

ok, that helps me narrow focus, I'll look at your TODO and proceed from there, thanks!

[sreuland]

@2opremio , tests are back to green, this looks ready to go now.

Related: #4760

We should probably incorporate a test making use of auth-next

Yes, the tests now use that Auth, populating with xdr.ContractAuth for token contract invocations.

[sreuland]

@2opremio @tamirms , tests are back in green. maybe we should merge at this point as #4757 criteria are met. I can capture the request for automation of wasm compilation that was raised here as follow on ticket.

[2opremio]

I can capture the request for automation of wasm compilation that was raised here as follow on ticket.

Sure!