455 create integration tests for stellar mainnet with archived proofs

[ebma]

Changes

• Run the integration tests for issue, redeem and replace requests also on Stellar mainnet. Only a small selection of integration tests are run on both Stellar mainnet and testnet because we can assume that if the tests of this selection pass, the rest will as well.
• Refactor code to pass around an is_public_network indicator where needed to differentiate between usage of Stellar testnet and mainnet instead of assuming testnet by default
• Change names of organizations in the default configuration of the stellar-relay pallet. (This is not a breaking change since the public keys did not change but it's good to keep it up-to-date)
• Changes the chain_spec to only include a configuration for Stellar testnet and mainnet. We can re-use most of the imports of the testnet runtime in the mainnet runtime but we cannot re-use the 'WASM_BINARY' (obviously, but this took me some time to figure out while debugging).
• command.rs assumes testnet by default. When running the standalone chain with cargo run --bin spacewalk standalone it will also use the testnet runtime. We can change it to make this configurable but I thought it might be best to keep it like this.
• The testnet and mainnet runtimes are perfectly the same, except for the IsPublicNetwork configuration parameter of the stellar-relay pallet. For this I also didn't find a better way than duplicating the runtime unfortunately.
• Update the overlay configuration files to use the latest versions.
• Move the rpc crate into the testchain directory. While trying the approach of deduplicated functions with traits it was necessary to have the rpc functions defined inside the node directory in order not to have circular dependencies. While I neglected that approach again, I think there is no good reason to keep the rpc crate separate from the node.

This PR unfortunately duplicates a lot of the code related to mainnet vs testnet execution of the standalone chain. I tried to deduplicate the functions by using respective traits but I failed to set this up correctly. Because it's quite cumbersome and already consumed too much time I decided to go ahead and duplicate the functions inserting the specific runtime and executor as required.

Closes #455.

[gianfra-t]

Looks great! Overall logic seems good. I have just one more comment that I think you addressed in the description.
I realize that start_instant_... is the same except for the corresponding call here to create the partial network elements. Is it not possible to de-duplecate the code because of the return types here?

[gianfra-t]

Is this account holding any real value?

[ebma]

It is, and it has to because it needs to have trustlines to some assets established in order to receive them 😬
We might want to give this task a higher priority to clean it all up but it's not that easy since we use a lot of different secrets which would need to be streamlined first.

[gianfra-t]

Oh okay, well we may want to delete this comment for now 😂.

[gianfra-t]

Can't we just call set_exchange_rate_and_wait? Or is this a placeholder for later adding more logic?

[ebma]

You are totally right, I removed it because it's redundant

[gianfra-t]

This default config is coming from the default implementation of the pallet, which is imported from spacewalk_runtime_testnet. Does the pallet itself implements the default config for mainnet?

[ebma]

Yes, the Default implementation of the pallet will use a relay configuration that works for Stellar mainnet, see here. Do you think it's confusing and we should make it more explicit here?

[gianfra-t]

It's fine! perhaps just a comment would be enough.

[ebma]

So the function start_instant.. is kind of where all the trouble begins. If you change it to something like

	let condition = is_public_network;
	let sc_service::PartialComponents {
		client,
		backend,
		mut task_manager,
		import_queue,
		keystore_container,
		select_chain,
		transaction_pool,
		other: (_, _, mut telemetry),
	} = if condition {
		new_partial_mainnet(&config, true)?
	} else {
		new_partial_testnet(&config, true)?
	};

Then you get

error[E0308]: `if` and `else` have incompatible types
   --> testchain/node/src/service.rs:539:3
    |
536 |       } = if condition {
    |  _________-
537 | |         new_partial_mainnet(&config, true)?
    | |         ----------------------------------- expected because of this
538 | |     } else {
539 | |         new_partial_testnet(&config, true)?
    | |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected struct `MainnetExecutor`, found struct `TestnetExecutor`
540 | |     };
    | |_____- `if` and `else` have incompatible types
    |
    = note: expected struct `PartialComponents<Client<Backend<Block<Header<u32, ...>, ...>>, ..., ..., ...>, ..., ..., ..., ..., ...>` (struct `MainnetExecutor`)
            the full type name has been written to '/Users/marcel/Documents/spacewalk/target/debug/deps/spacewalk_standalone-45c9a89cc04beb28.long-type-8402217824377730313.txt'
               found struct `PartialComponents<Client<Backend<Block<Header<u32, ...>, ...>>, ..., ..., ...>, ..., ..., ..., ..., ...>` (struct `TestnetExecutor`)
            the full type name has been written to '/Users/marcel/Documents/spacewalk/target/debug/deps/spacewalk_standalone-45c9a89cc04beb28.long-type-6705364446283919034.txt'

error[E0599]: no method named `clone` found for struct `Arc<_>` in the current scope
   --> testchain/node/src/service.rs:545:19
    |
545 |             client: client.clone(),
    |                            ^^^^^ method not found in `Arc<_>`

error[E0599]: no method named `clone` found for struct `Arc<_>` in the current scope
   --> testchain/node/src/service.rs:546:39
    |
546 |             transaction_pool: transaction_pool.clone(),
    |                                                ^^^^^ method not found in `Arc<_>`

This means we have to make the return type of the new_partial_... functions more generic so that they return the 'same' type but you have to go further down the rabbit hole in each function to make everything genereic and eventually, I encountered too many issues that I was not able to resolve unfortunately. It has to be possible, but I'm not sure if it's worth it to spend more time on this. WDYT @gianfra-t? Would it be worth to do so?

[gianfra-t]

Okay I imagined it was something like this, I was also thinking exactly something like:

= if condition {
		new_partial_mainnet(&config, true)?
	} else {
		new_partial_testnet(&config, true)?
	};

But If this or something similarly simple won't work, I don't think it is worth it.

[gianfra-t]

Good to go for me! The tests passed for the Ubuntu variant so it should be okay.

[ebma]

Thanks for the review @gianfra-t 👌 . I'll leave this open until tomorrow in case someone else from @pendulum-chain/devs wants to review it (since we said we'd want to have 2 reviewers).

[ebma]

I'll merge this now since the CI passed.