Better support for deploying to non-home tenant

[pamelafox]

Purpose

I've been deploying to my non-home tenant this week, and it's been tricky since DefaultAzureCredential doesn't necessarily know which tenant to use. Its chain is:

1. AzureCliCredential - which can have a default tenant override, if explicitly set
2. AzureDeveloperCliCredential - doesn't have a default tenant override, but will obey tenant_id or AZURE_TENANT_ID in global env

So sometimes my DAC will work, if I've got my az or env setup right, but often it will break.
This change makes our code more explicitly pass in the tenant_id for local use, which should be set by the azd up process.
However, its slightly backward incompatible as we were bringing tenantId into main.parameters.json, which was overriding what would otherwise be a correctly output tenantId and setting it to an empty string. So some developers may need to re-run azd provision, or go into their .env and set AZURE_TENANT_ID="" there, to get local dev working again.

Does this introduce a breaking change?

When developers merge from main and run the server, azd up, or azd deploy, will this produce an error?
If you're not sure, try it out on an old environment.

[X] Yes - See above
[ ] No

Does this require changes to learn.microsoft.com docs?

This repository is referenced by this tutorial
which includes deployment, settings and usage instructions. If text or screenshot need to change in the tutorial,
check the box below and notify the tutorial author. A Microsoft employee can do this for you if you're an external contributor.

[ ] Yes
[X] No

Type of change

[x] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Documentation content changes
[ ] Other... Please describe:

Code quality checklist

See CONTRIBUTING.md for more details.

• The current tests all pass (python -m pytest).
• I added tests that prove my fix is effective or that my feature works
• I ran python -m pytest --cov to verify 100% coverage of added lines
• I ran python -m mypy to check for type errors
• I either used the pre-commit hooks or ran ruff and black manually on my code.

[pamelafox]

CCing everyone who I've discussed DefaultAzureCredential woes with :)

[tonybaloney]

Why does this one not have the same timeout?

[pamelafox]

I don't know! I thought about removing it for consistency but then thought I shouldnt change things I dont know the origin for. Maybe @mattgotteiner recalls a reason?

[pamelafox]

Maybe we should put the timeout in both, just to give the credential more time to come back locally.

[mattgotteiner]

I don't think adding the timeout will have much issue. Sure, we can add it to both

[pamelafox]

Fix for AZ CLI regression-
Azure/azure-cli#29828

[mattgotteiner]

It's unfortunate DefaultAzureCredential didn't work here

[pamelafox]

@mattgotteiner It works only if you're also logged into Azure CLI and have explicitly set your tenant's subscription to the one that was used in the app. So I think it's safer to go with the more explicit credential. We'll see if we get more/less issues with this sort of approach.