Add optional reqwest-middleware feature

[wfchandler]

Add a new middleware feature that allows users to opt into using reqwest_middleware::Client instead of reqwest::Client. This enables users to enable automatic retries or tracing in their application.

[wfchandler]

The diff on this PR is unfortunately quite large due to duplication of each test output file with the middleware FF enabled.

[wfchandler]

This will be consumed by oxidecomputer/oxide.rs#1035

[wfchandler]

Do we want to update CI to run tests and/or builds with this feature enabled?

[ahl]

Can you give me context on why we're doing this and where we intend to use it?

Does this make sense as a cargo feature? Recall that features apply across the compilation so eg using this feature for one client crate would break the use of an unrelated client crate that did not intend to use the feature.

[wfchandler]

Can you give me context on why we're doing this and where we intend to use it?

This enables us to generate logs for API calls in oxide.rs, see oxidecomputer/oxide.rs#1035 for the implementation.

Does this make sense as a cargo feature? Recall that features apply across the compilation so eg using this feature for one client crate would break the use of an unrelated client crate that did not intend to use the feature.

I think it's the least worst option:

1. Replace reqwest::Client with reqwest_middleware::ClientWithMiddleware. Breaking change for all dependents of Progenitor, many of whom may not want to use middleware.
2. Add an additional progenitor::ClientWithMiddleware that we populate with all methods we generate for progenitor::Client. Avoids the feature flag, but doubles the amount of codegen, slowing builds and bloating binaries.
3. Feature flag for middleware, this PR. No additional codegen, dependents can opt into middleware if desired. Looking through the packages listed as dependents on crates.io, I don't see any that have multiple Progenitor clients being generated, but of course we don't know about any non-public usage.

[ahl]

A couple of options that seem potentially palatable

4. Settings-based configuration for codegen
5. Abstracting the client to be a trait for which we provide impls e.g. for reqwest::Client

I don't see option 3 as viable.

[wfchandler]

A couple of options that seem potentially palatable

4. Settings-based configuration for codegen
5. Abstracting the client to be a trait for which we provide impls e.g. for reqwest::Client

I don't see option 3 as viable.

A settings option is much cleaner, thanks! I've opened #1079, will close this out.