[dev-tool] Allow samples to use createTestCredential

[maorleger]

Packages impacted by this PR

@azure-tools/dev-tool

Issues associated with this PR

Contributes to #30447

Describe the problem that is addressed by this PR

Using AZURE_POD_IDENTITY_AUTHORITY_HOST as a workaround was necessary because we wanted to continue using DefaultAzureCredential in samples but skip Managed Identity when
running samples.

In tests, we use createTestCredential which works well but is not the credential we want to showcase
in sample code.

This PR allows us to use createTestCredential in samples-dev (which will be run by CI) while still promoting DAC
as the credential to use in sample code.

What are the possible designs available to address the problem? If there are more than one possible design, why was the one in this PR chosen?

Are there test cases added in this PR? (If not, why?)

Provide a list of related PRs (if any)

Command used to generate this PR: (Applicable only to SDK release request PRs)

Checklists

• Added impacted package name to the issue description.
• Does this PR need any fixes in the SDK Generator?** (If so, create an Issue in the Autorest/typescript repository and link it here.)
• Added a changelog (if necessary).

[azure-sdk]

API change check

API changes are not detected in this pull request.

[maorleger]

Regenerated samples for the entire repo and inspecting output

So far so good, but I expect it to no-op in most places (except keyvault-keys which now uses creataeTestCredentail)

[maorleger]

This is kinda weird, and can ben confusing. Maybe we remove that comment anywhere we have it but not sure

[timovv]

Changes look good to me.

This is not a strong opinion, and I don't want to block things, but I am having minor second thoughts about the approach. It feels a bit strange to me that the samples in samples-dev/ don't match the output in samples/, in what feels like a significant difference in actual runtime behavior (as opposed to what we were doing already, where although we do transform the samples, the output code does the same thing as the input).

The actual approach of doing the transformation looks good to me, though. If it's not too much effort maybe we could go the other way, and transform from DefaultAzureCredential to createTestCredential on the fly when we are executing the samples in the pipelines? That way, while there will still be a mismatch between the samples that are getting run and what we have checked in, at least the two versions that we have checked in will match.

If you're happy with the current approach though I am more than happy to go ahead with it, I can see arguments either way

[maorleger]

Closing per offline discussion, we prefer to go in another direction so this is obsolete