SUP-6598: update-public-ephemeral-spark-example

[zbpvarun-tamr]

The purpose of this PR is to update our public facing terraform example for using ephemeral spark on an AWS deployment. This uses the code that we most recently performed scale-testing on. There are a lot of changes in here that I'm not sure if they can be done / have been done correctly. Some of my concerns are:

1. I switched from using a local.tfvars file to using .tf files. Can this be used by customers as well?
2. Some of our files, like the label.tf file which provides the tag refers to a labels module that is internal only. I excluded the reference to this module when setting up the file. But I am not sure if this will work as intended if used by customers.
3. The provider.tf file in the example I pulled from has references to where the output should be saved (our GCP backend). How should this be referenced for customers? Or will this just not work and should I be sticking to the previous format of using local variables and outputs?

[souza-dan]

The purpose of this PR is to update our public facing terraform example for using ephemeral spark on an AWS deployment. This uses the code that we most recently performed scale-testing on. There are a lot of changes in here that I'm not sure if they can be done / have been done correctly. Some of my concerns are:

1. I switched from using a local.tfvars file to using .tf files. Can this be used by customers as well?
2. Some of our files, like the label.tf file which provides the tag refers to a labels module that is internal only. I excluded the reference to this module when setting up the file. But I am not sure if this will work as intended if used by customers.
3. The provider.tf file in the example I pulled from has references to where the output should be saved (our GCP backend). How should this be referenced for customers? Or will this just not work and should I be sticking to the previous format of using local variables and outputs?

1. Generally, variables are good for modules and examples and locals are good for concrete usage. The examples are abstracted a bit since we don't concretely know what environment they'll be used in.
2. Tagging is very important part of using AWS. Policies are often enforced via tags. Give that it's a freeform field, the standards will vary from user to user, but having showing off a generic way of adding tags that a user of this module could adapt sounds good to me.
3. These examples can't assume too much how the state should be managed. That will vary quite a bit based on the user of the module, since there are lots of ways Terraform pipelines are managed. All we can really do is define the providers that the examples require.