Decouple from stellar/go monorepo

[leighmcculloch]

What

Remove ConvertBytes/Interface methods and add XDR type string constants.

Why

This is a follow up to:

• Karthik/fix deps #3 (comment)

The current exported interface with ConvertBytes and ConvertInterface encourages using the types defined outside the package, i.e. from the Go monorepo, as a name enum of sorts. Those types happen to be named the same, which is lucky given that if the Go types were named according to Go naming conventions they wouldn't match the Rust names encoded in the stellar-xdr Rust crate. The coupling is sort of convenient when using the stellar/go/xdr package, but otherwise the interface is very unintuitive.

Instead of the approach taken today, where another packages types are used as an enum, this package could provide a list of constants for all the types, and that would provide the same amount of certainty if folks were wanting to avoid having hardcoded strings.

Close #4

Notes

Generation of Type Constants

The constants are generated using the stellar-xdr Rust crate, so that the list of constants will always be up to date and match the underlying crate.

Rename of Convert* function to Decode

The function is renamed to align with the naming of the same operation in the stellar-cli xdr command, and the js-stellar-xdr-json package's exported interface. Some common nomenclature is helpful when maintaining a series of libraries and tools that export the same functionality.

Todo

• Spike a modification of the stellar-rpc update required to ensure no surprises.

Merging

This PR should be merged after the PR below so that CI is in place:

• Add binaries and CI workflow for multi-arch binary verification #7

[chowbao]

+1 to the type strings

Need @2opremio and @Shaptic reviews for Decode and interface changes as it impacts RPC