471 clean up stellar secret keys

[gianfra-t]

Closes #471

Makes use of environmental variables for the stellar secret keys instead of reading them from the resources files, when running tests. We don't use clap for passing the keys given that is not straightforward to use with cargo test.

We maintain the usage of the same cli commands where we specify the stellar_vault_secret_key_filepath, but use the environment keys for testing.

The use of DEFAULT_MAINNET_DEST_SECRET_KEY and DEFAULT_TESTNET_DEST_SECRET_KEY is now replaced by destination keys read from environment. In order to keep the use of only 4 consistent source and destination keys, the keys previously supplied from by these constants are changed.

NOTE: the tests should be failing until we add the github secrets corresponding to the stellar keys.

[ebma]

Looks good to me overall 👍 just left minor comments.

Do you have permissions to add secrets to this repository? We still need to migrate the accounts that are removed as part of this PR. I propose we create two new accounts per Stellar network (ie. 4 in total, not re-using secret keys for both networks) and then migrate the assets and trustlines that are currently held in the accounts here to the new accounts. Do you think you'd be able to do this @gianfra-t? I can also give you some guidance.

[gianfra-t]

@ebma Thanks for the comments. After I change the code for the suggestions I think I can "migrate" the accounts. Just to verify, all 4 accounts need to have the same trustliness and the only difference is that source accounts will have the asset in question right? Also, all 4 need some amount of lumen.

[b-yap]

After we identify the accounts, we will need to add a step (setting up the environment variable) in the github actions, yes?

[ebma]

I replaced some other keys so that the 4 accounts supplied via env variables are really the only important ones.

The tests, rustfmt and clippy checks passed on my machine so I think we are good to merge it right away (without waiting for the CI because it might fail due to the sysinfo crate issue that is only fixed in this PR. )