Add support for running both a TESTNET and an alpha PUBLIC network Turret

[kalepail]

We're finally ready to take our first (very safe) steps in the universe of public network Turrets! 🎉

This PR adds all the necessary config and script changes to make this functionality possible.

Note that when the STELLAR_NETWORK = "PUBLIC" a new check will come into play on the txFunction upload endpoint blocking all contract uploads except for those hashes which have been manually added to the new ALLOWED KV store.

So here are the necessary steps to get everything up and running.

1. As per a community Discord discussion the name of Stellar Turrets has changed from TSS to Stellar Turrets so I'm phasing out stellar-tss or tss-stellar in favor of stellar-turrets. (note I'll probably change the name of this repo as well). Because of this change you'll likely need to delete your AWS deployment and spin up a new one under this new name. AWS is weird with name changes. To do that just navigate into your AWS console under CloudFormation and delete the tss-stellar stack.
2. Next we need to reconfigure the existing testnet Wrangler deploy to match the new name. This is as simple as just going into the Wrangler dashboard and manually renaming it to, in my case, stellar-turrets-testnet. You could also delete the existing Worker as it would get recreated the next time you deploy. For the KV navigate to the KV tab and re-prefix the existing KV stores with the new stellar-turrets-testnet. For Cloudflare these changes are more cosmetic than necessary as CF works of ids not names of things, but it should help in the future if we start matching everything with their name.
3. Next we need to add the stellar-turrets-alpha to our Cloudflare account. The best way to accomplish this is first to run the setup.sh script from within the ./wrangler directory again. You may need to comment out the commands for the existing testnet KV stores but I think it should just error out or skip those. Keep track of the alpha outputs and I strongly suggest using a new Stellar key for the TURRET_SIGNER than you're using for the testnet.
4. Once you've got your new (and old) KV ids you're ready to run the npm run preinit and then npm run init. As the script walks you through the flow just paste in all the appropriate values. If you've forgotten what they were or are they should be in the old .env file or in the Cloudflare dashboard.
5. Assuming this all worked you should now have a wrangler.toml file and stellar.toml file which "check out", full of meaningful and appropriate values. Feel free to edit or modify as necessary. The init and preint scripts are helpers not have-tos.
6. You can now deploy the wrangler scripts with wrangler publish (for testnet) and wranger publish --env alpha (for alpha, duh)
   6.1. On the first publish of a new --env you'll need to also create the Durable Object so you'll need to run the publish command with the --new-class TxFees flag. So in the case of an alpha publish it would be wrangler --env alpha --new-class TxFees publish
7. Finally we move to the ./serverless directory and run npx envdist testnet and npx envdist alpha and fill in the appropriate values. Note if you already have a .env file you can delete that as we'll now be creating and relying on .env.testnet and .env.alpha for the deploy process. Once those are built you should be able to just run sls deploy (for testnet) and sls deploy --stage alpha (for alpha, again, duh)
8. Assuming these all go off without a hitch you should be fully setup with both a testnet and an alpha public network Turrets! Remember to go back to the Wrangler vars and fill in the {TESTNET|ALPHA}_TURRET_FUNCTION_RUNNER_URL values if you didn't have them earlier. Same goes for the SLS_TURRET_BASE_URL variable in the Serverless env files. The deployments are only as good as your configuration so please ensure you've done it right.
9. Finally please please please use different {TESTNET|ALPHA}_TURRET_ADDRESS/SLS_TURRET_SIGNER_ACCOUNT addresses between your testnet and alpha Turrets. Duplicating these is a bad idea as a leak to a Testnet key is no big deal but a leak on the public network could equal loss of funds. The time to be safe is now!

If any of these instructions were wrong, incomplete or out of order please comment here so we can adjust. Good luck!

[kalepail]

Note this PR breaks the current GitHub Actions for Serverless. The current flow alters the env variables depending on which Turret you're deploying. With GitHub secrets you would have to set once either for testnet or alpha but it wound't support deploying to both. Will need to address this before merging to master.

[stevenjohn]

I have worked through this, it went pretty smoothly. We now have:

https://stellar-turrets-testnet.taskio.workers.dev
https://stellar-turrets-alpha.taskio.workers.dev

Here's my notes:

• I don't see an option to set the AWS region - did I miss it? Important as we want different regions and we'd default to UK as a Uk business.

• Need to add requirement to add the new class for threes, i.e.
  wrangler publish —new-class TxFees
  wrangler —env alpha publish —new-class TxFees

Minor notes to keep in mind for when we create new instructions after master merge:

• When creating KVs for alpha, use cmd
  npx wrangler —env alpha kv:namespace create “META”
  npx wrangler —env alpha kv:namespace create “TX_FUNCTIONS”

• You must run the extra
  npx wrangler —env alpha kv:namespace create “ALLOWED”
  ...to create this new KV for Alpha

Cheers

[kalepail]

I don't see an option to set the AWS region - did I miss it? Important as we want different regions and we'd default to UK as a Uk business.

See https://www.serverless.com/framework/docs/providers/aws/guide/serverless.yml and grep for region. It's a key : value in the provider object in the serverless.yml file. It's currently unset to anything so will default to the default region for your AWS account.

[kalepail]

Need to add requirement to add the new class for threes, i.e.
wrangler publish —new-class TxFees
wrangler —env alpha publish —new-class TxFees

This is in the current README however it isn't included here that when publishing for the alpha env you'll need to publish an additional Durable Object class via the --env alpha flag. Nice catch!