Prioritize assume role credentials and deprecate built-in network providers

[arandito]

Description

This PR aligns credential resolution behavior with the modular credential chain spec changes:

• Resolves assume-role profiles before profile session or static keys.
• Defers profile key providers when the selected profile declares role_arn.
• Suppresses environment credentials when an explicit profile_name is provided.

This PR also deprecates the built-in IMDS and container resolvers in favor of aws-credentials-imds and aws-credentials-http.

Testing

• Added unit coverage for the new precedence and deferment behavior.
• Confirmed new behavior with aws-credentials-sts package and aws-sdk-sts client

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[Alan4506]

[The comment applies to line 81 as well]

With this deferment, consider a user whose profile looks like:

[default]
aws_access_key_id = AKIA...
aws_secret_access_key = ...
role_arn = arn:aws:iam::123:role/Foo
source_profile = default

but who doesn't have aws-credentials-sts installed. The profile key providers now defer, the assume-role provider isn't discovered, and _find_unclaimed_sources can't flag it either - PROFILE_ASSUME_ROLE.is_detected() is always False. So the user gets an IdentityChainError with no "install aws-credentials-sts" suggestion, but the SEP says the point of deferring is that "the chain reports the missing STS module".

Is this a gap we should address?

[arandito]

I am aware of this gap. However adding it to this PR expands its scope. This PR focuses on behavioral changes we want to get in before our next release. The module suggestions improves customer experience but doesn't change behavior.

I already have a follow up PR to add better module suggestions which will add profile based provider suggestions to ChainSetup at the SharedConfigProvider. We should try to squeeze it in but can definitely wait until a future release.

[Alan4506]

PR #771 passes config_context.profile_name into IdentityChain.create(), but it looks like SharedConfigContext.profile_name is never None? It falls back to AWS_PROFILE, then default.

smithy-python/packages/smithy-aws-core/src/smithy_aws_core/config/context.py

Lines 184 to 201 in c0150aa

	def _resolve_profile_name(
	self, explicit_profile: str | None
	) -> tuple[str, str | None]:
	"""Determine the active profile name and where it came from.
	Priority: explicit argument > AWS_PROFILE env var > "default"
	:returns: Tuple of (profile_name, origin), where origin describes the
	source for error messages and is None when the name was defaulted.
	"""
	if explicit_profile is not None:
	return explicit_profile, "the profile argument"
	env_profile = os.environ.get(_PROFILE_ENV_VAR)
	if env_profile is not None:
	return env_profile, _PROFILE_ENV_VAR
	return _DEFAULT_PROFILE, None

So once both PRs land, a user with just AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY set and
no profile configured still gets the environment provider skipped.

Since the context already tracks profile_origin, should #771 pass the profile only when it came from the explicit argument?

[arandito]

Good catch. I'll update #771 to only set the profile if its origin is an explicit override.