Config client from profile

[tomwheeler]

DO NOT MERGE.

I have created this draft PR to support review and sharing this code. However, I do not intend for this code to become part of the main branch right now.

What was changed

I added code to configure the Temporal Client from a configuration file that defines a named profile, which specifies the frontend address of the Temporal Service, the Namespace, and details related to the desired authentication method. It uses the default location of the configuration file, but the profile name to use within it is specified through an environment variable. The Worker and Starter code use the Client returned by this code.

Why?

Currently, the clients used in this tutorial have no explicit configuration and rely solely on the default options. Imagine that someone new to Temporal application development signed up for Temporal Cloud on their own and now wants to run this intro-level money transfer tutorial. Getting it to work with Temporal Cloud requires making changes to the Client configuration, but this user won't know what to change. Note that this scenario I've described isn't limited to Temporal Cloud. Someone using a non-default Namespace name or a non-local Temporal Service would have the same problem.

Having the clients configure themselves based on the presence of environment variables eliminates the need to hardcode the frontend address, Namespace name, or authentication details. It helps the user understand that the application logic remains unchanged when migrating from the Temporal Service used for development on their laptop to a production Temporal Service (or vice versa). Finally, this makes it easier for users to run this example locally, on a remote self-hosted cluster, or on Temporal Cloud.

This updated takes advantage of the pre-release support for profile-based configuration in the Python SDK.

NOTE: I have updated the code but not the prose in the tutorial, pending further discussion with the Education team. I plan to make similar changes to the other money-transfer repos, but if it turns out that is not viable, then I will probably need to fork these repos and tutorials to support the onboarding path for new cloud users.

Checklist

1. Closes

This does not close an issue, but enables further progress of EDU-3801. That issue would be closed only after all similar tutorials have been updated.

2. How was this tested:

I tested this by first creating a profile named cloud using the Temporal CLI (note that these values are similar to but not identical to the ones I actually set):

$ temporal --profile cloud config set --prop address --value "us-east-1.aws.api.temporal.io:7233"
$ temporal --profile cloud config set --prop namespace --value "example.c9ef8"
$ temporal --profile cloud config set --prop api_key --value "abc123.actual.value.redacted.xyz789"

According to the output from this command, the config file was created at $HOME/Library/Application Support/temporalio/temporal.toml.

I then set an environment variable:

export TEMPORAL_PROFILE=cloud

I started the Worker, opened a new terminal tab and set the same environment variables above, and started the Workflow. I verified in the Temporal Cloud Web UI that the Workflow Execution ran and completed successfully.

3. Any docs updates needed?

The tutorial prose will require a small update to describe the changes and explain which environment variable one must set for non-default scenarios.