As indicated in #1549, there is an issue with hyper (the underlying
layer used by reqwest) that hangs in some cases on connection pools.
This PR uses a commonly discussed workaround of setting
`pool_max_idle_per_host` to 0.
Ref: https://github.com/hyperium/hyper/issues/2312
* include source stack in aggregated errors in DefaultAzureCredential
As indicated in #1543, error details are swallowed when building an
aggregate error message.
Currently, we format each of the errors using to_string, which results
in the following:
```
Error {
context: Full(
Custom {
kind: Credential,
error: Error {
context: Message {
kind: Credential,
message: "Multiple errors were encountered while attempting to authenticate:\nenvironment credential\nIMDS timeout\naz-cli",
},
},
},
"failed to get bearer token",
),
}
```
This doesn't help the user understand how to fix the issue.
With this update, we recurse through the error sources, building a more
detailed message. This results in:
```
Error {
context: Full(
Custom {
kind: Credential,
error: Error {
context: Message {
kind: Credential,
message: "Multiple errors were encountered while attempting to authenticate:\nenvironment credential - request token error - Server returned error response\nIMDS timeout - operation timed out\naz-cli - 'az account get-access-token' command failed: ERROR: AADSTS70011: The provided request must include a 'scope' input parameter. The provided value for the input parameter 'scope' is not valid. The scope https://storage.azure.com/ offline_access openid profile is not valid. The scope format is invalid. Scope must be in a valid URI form <https://example/scope> or a valid Guid <guid/scope>. Trace ID: 346f391a-48f2-4e96-849f-9ecd6c589d02 Correlation ID: 7888c325-56ff-4100-8ce2-c8cf41561b40 Timestamp: 2024-01-05 01:31:04Z\nInteractive authentication is needed. Please run:\naz login --scope https://storage.azure.com/\n",
},
},
},
"failed to get bearer token",
),
}
```
When printed, this message looks like:
```
Multiple errors were encountered while attempting to authenticate:
environment credential - request token error - Server returned error response
IMDS timeout - operation timed out
az-cli - 'az account get-access-token' command failed: ERROR: AADSTS70011: The provided request must include a 'scope' input parameter. The provided value for the input parameter 'scope' is not valid. The scope https://storage.azure.com/ offline_access openid profile is not valid. The scope format is invalid. Scope must be in a valid URI form <https://example/scope> or a valid Guid <guid/scope>. Trace ID: 02aecb08-69b4-4a5d-9ebb-784ea788c102 Correlation ID: dddc061a-ca11-4b21-b857-6d765a564597 Timestamp: 2024-01-05 01:43:45Z
Interactive authentication is needed. Please run:
az login --scope https://storage.azure.com/
```
As identified in #1479, we do not currently handle deleted/renamed specifications well.
This update addresses this via the following:
* Moves to using parsing `cargo_toml` to parse services/Cargo.toml to know what crates already exist
* Replaces all uses of `list_crate_names` with using the results of `gen_crates`
As a byproduct, this identifies that the previously existing spec that would result in `azure_svc_codesigning` was removed.
ref: https://github.com/Azure/azure-rest-api-specs/pull/26635
Most of the time, tag is analogous to "API version", but not always. The idea is to allow the following:
* Allow the generated crate user to specify which tags they want if they want something specific
* Allow the SDK developer to rely on the "usual" behavior where it's API version, and use the "latest" without having to continuously update the SDK crate based on a steady churn of the generated crates
* When user uses both the generated crate and the SDK-crate, it doesn't violate either of the above ideals
* Allow users to use both generated crates and the SDK-crate _without_ multiple imports of the same crate as the generated crates can be huge. (For reference, azure_svc_blobstorage is ~5M of source, and each feature is ~1M)
This change modifies the generated import behavior thusly:
* Any tag that is selected by feature name is available for use via `use crate_name::tag_name::models;`
* If the `default_tag` feature is selected, then the tag is included by feature name (and can be used via `use crate_name::tag_name::models;`
* If the `default_tag` feature is selected, then the implementation for that specific tag is imported at the top level for the crate, such that it can _also_ be used as `use crate_name::models;`
This includes two changes:
1. Align `to_xml` to `to_json` by returning Bytes instead of String
2. Updates generator to use `to_xml` when the content-type is set to `application/xml`
This does 3 things:
1. Renames `AccessToken` to `Secret`
2. Prevents `Debug` of the `AccessToken` from actually showing the secret
3. Starts expanding the use of `Secret` to other areas, such as client certificates