[rust-server] enhance support for middlewares

[bjgill]

PR checklist

• Read the contribution guidelines.
• Ran the shell script under ./bin/ to update Petstore sample so that CIs can verify the change. (For instance, only need to run ./bin/{LANG}-petstore.sh and ./bin/security/{LANG}-petstore.sh if updating the {LANG} (e.g. php, ruby, python, etc) code generator or {LANG} client's mustache templates). Windows batch files can be found in .\bin\windows\.
• Filed the PR against the correct branch: master, 3.1.x, 4.0.x. Default: master.
• Copied the technical committee to review the pull request if your PR is targeting a particular programming language. @frol @farcaller

Description of the PR

This enhances codegen to generate the new RequestParser trait, so middlewares can get the operation ID from a hyper Request. This PR also tweaks the autogenerated client to be generic over the future type that the underlying hyper Client returns. This is needed to allow passing wrapped clients - the FutureResponse type used originally is private to hyper and can't be constructed. This change allows us to wrap the hyper client below the autogen layer but above hyper.

I've not done any manual testing of this PR - we've been using this in production for the past month, though, so low risk.

Thanks to @mthebridge, who originally contributed these changes.

Part of the fix for #550

[wing328]

@bjgill thanks for the PR. Is it correct to say that this PR is a breaking change for the Rust client?

If yes, we should include it in 3.2.x branch instead.

[bjgill]

@wing328 - this will only be a breaking change if the user has put the Client's type signature in their code. Otherwise, no changes are needed - e.g. for the example client integration. Any migration should be straightforward - they'll just need to update their type signature to match the new one.

Given that rust-server is in the list of generators not yet fully migrated, do we actually need to abide by the stability guarantees implied by the versioning of openapi-generator as a whole? There is going to be at least one more breaking PR before I'm ready to do any serious testing of rust-server.

However, if it's not acceptable to keep rust-server unstable for the moment, we probably do need to move active development onto the 3.2.x branch. Do you know what the expected release date for that is?

(Also, I've noticed that we weren't previously checking that the example integration compiled, so have just fixed that in the latest commit.)

[wing328]

Given that rust-server is in the list of generators not yet fully migrated, do we actually need to abide by the stability guarantees implied by the versioning of openapi-generator as a whole? There is going to be at least one more breaking PR before I'm ready to do any serious testing of rust-server.

In the migration guide, I've updated rust-server as "migrated". Only the apex generator is pending migration and testing at the moment.

[wing328]

this will only be a breaking change if the user has put the Client's type signature in their code. Otherwise, no changes are needed - e.g. for the example client integration. Any migration should be straightforward - they'll just need to update their type signature to match the new one.

Thanks for the explanation.

If this PR is ready to merge, please kindly let me know.

[bjgill]

Thanks. This is ready to merge.