Update bindings to use the reqwest-trait template

[dani-garcia]

🎟️ Tracking

📔 Objective

This template is trait based which should allow easier mocking. It also follows a similar pattern to our clients which I think would make it easier to use.

The PR is in three commits:

• Use request-trait template contains:
  • Updated cargo toml to include new dependencies
  • Updated build script to run format again, due to what looks like a rustfmt bug
  • Updates to templates
    • Use uuid instead of &str
    • Change the use of async_trait to be ?Send. This is needed because reqwest in WASM is not Send.
    • Updated the generated docs to point to the correct function. (This has been upstreamed)
    • Simplified lifetimes, as we don't really use any references (they can't be entirely removed as mockall requires them)
• 🤖 Generate bindings: Generate the bindings using the template from the previous step. this is based on the same server bindings as Update OpenAPI version and templates #296
• Update code to new api. Updated our code to build with the new template, most changes are very simple API adjustments, the biggest changes are in the client/internal.rs file and consist in modifications to how we initialize and update the ApiConfigurations struct to match the newer API.

PR review recommendation

For vault

Filter by team owned, the only vault change is a small update in the /sync code:
689da35 (#343)

For platform

Due to the big autogenerated changes, I recommend reviewing commit by commit. The first and last commits should be reviewed as normal. The middle commit, marked as 🤖, should instead be reviewed by regenerating the bindings and making sure that nothing is changed:

cd server
git checkout 29dc69a77b7b1a781dc93cbbcd4bf5475184ddf1

dotnet tool restore
cd src/Api
dotnet build
dotnet swagger tofile --output "../../api.json" --host "https://api.bitwarden.com" "./bin/Debug/net8.0/Api.dll" "internal"

cd ../../src/Identity
dotnet build
ASPNETCORE_ENVIRONMENT=development  dotnet swagger tofile --output "../../identity.json" --host "https://identity.bitwarden.com" "./bin/Debug/net8.0/Identity.dll" "v1"

cd ../../../sdk-internal
git pull
git checkout ps/migrate-to-openapi-rust-trait
./support/build-api.sh

cargo +nightly fmt
# Ignore the cargo.toml files, which get updates from renovate
git checkout crates/bitwarden-api-api/Cargo.toml
git checkout crates/bitwarden-api-identity/Cargo.toml

git status
# This should report a clean work tree

I have a server PR including a script to make this easier next time: bitwarden/server#6066

⏰ Reminders before review

• Contributor guidelines followed
• All formatters and local linters executed and passed
• Written new unit and / or integration tests where applicable
• Protected functional changes with optionality (feature flags)
• Used internationalization (i18n) for all UI strings
• CI builds passed
• Communicated to DevOps any deployment requirements
• Updated any necessary documentation (Confluence, contributing docs) or informed the documentation
  team

🦮 Reviewer guidelines

• 👍 (:+1:) or similar for great changes
• 📝 (:memo:) or ℹ️ (:information_source:) for notes or general info
• ❓ (:question:) for questions
• 🤔 (:thinking:) or 💭 (:thought_balloon:) for more open inquiry that's not quite a confirmed
  issue and could potentially benefit from discussion
• 🎨 (:art:) for suggestions / improvements
• ❌ (:x:) or ⚠️ (:warning:) for more significant problems or concerns needing attention
• 🌱 (:seedling:) or ♻️ (:recycle:) for future improvements or indications of technical debt
• ⛏ (:pick:) for minor or nitpick changes

[Hinton]

Should we open upstream issues and see if any of the changes can upstreamed?

It would be interesting to see how the mocked usage would be as a comparison to using wiremock.

[dani-garcia]

I'm planning to upstream the doc link issue at least, which clearly seems like a mistake. Probably also the removing Send bound, which seems safe. The rest could be harder:

• Using str for uuids seems intentional for the templates, as it's happening in all variants, even though they use the uuid type in other places.
• The lifetimes change is mostly stylistic, as it simplifies the generated code a bit, but there may be cases where it's useful to have separately named lifetimes, not sure.
• The APIclient initialization is fairly subjective on whether it should eagerly initialize all the subclients or to initialize them on each call. To me it makes more sense to do it on each call than to initialize the 60 of them at the same time, but for smaller APIs maybe that doesn't matter

The mocks look something like this: 77e2333