Update bindings to use the reqwest-trait template

[dani-garcia]

🎟️ Tracking

https://bitwarden.atlassian.net/browse/PM-25542

📔 Objective

Note: The PR is absolutely massive because the generated code is very verbose (something that I plan to optimize in the future) and github is pretty bad about filtering out whitespace changes 😞. To facilitate review I include some recommendations at the bottom of this block.

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:

let config = client.internal.get_api_configurations().await;

// Old API
let res = bitwarden_api_api::apis::projects_api::projects_create(
    &config.api,
    input.organization_id,
    project,
).await?;

// New API
let res = config.api_client
    .projects_api()
    .create(input.organization_id, project)
    .await?;

The provided mocks are also typesafe and easy to use:

        let api_client = ApiClient::new_mocked(move |mock| {
            mock.folders_api
                .expect_post()
                .returning(move |model| {
                    Ok(FolderResponseModel {
                        id: Some(folder_id),
                        name: Some(model.unwrap().name),
                        revision_date: Some("2025-01-01T00:00:00Z".to_string()),
                        object: Some("folder".to_string()),
                    })
                })
                .once();
        });

PR structure

The PR is split in four commits:

• Update OpenAPI and templates to latest version: Updates the openapi generator and the templates to the latest version. These files should match with the files at https://github.com/OpenAPITools/openapi-generator/tree/ee40887d47f6d7a16318772f49c63b8eb0553488/modules/openapi-generator/src/main/resources/rust I've also gone ahead and deleted some unused files to make it clearer which files are being used.
• Add our changes to the templates
  • Updates to templates
    • README.mustache: Added the server commit hash to the readme
    • model.mustache and model_mod.mustache: Remove double option pattern, as we don't differentiate between not required and nullable, and they just add noise.
    • api.mustache: Made async-traits ?Send to support WASM
    • api.mustache: Used our custom x-action-name instead of operationID, so that function names are just functionName instead of ControllerName_FunctionName
    • api.mustache: Filtered deprecated operations out, no need to generate code for them when they shouldn't be used
    • api.mustache: Use uuid instead of &str for request parameters
    • api.mustache: Replaced all the function lifetimes by a single one. Previously it would create one per parameter, which is more flexible but made for some terrible function signatures.
    • api_mod.mustache: Replaced the root Api trait and implementations by a single ApiClient enum with both real and mock impls. This is functionally the same but allows the compiler to better optimize out the unused functions (from 3.7MB to 2.2MB WASM blob size)
• 🤖 Generate bindings: Generate the bindings using the template from the previous step. this is based on the server bindings from bitwarden/server@d384c0c
• 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

As this PR edits the generated bindings, the total changes are huge and difficult to review. As such, I've written a suggested review guide for the teams.

For vault/auth

Filter by team owned, the vault/auth related changes are fairly small:

• small update in the /sync code to use the new API
• updated the folder API code to use the new API and new mocks
• updated the send access code to use the new configuration

If filtering by team owned doesn't work, the non-platform changes are contained entirely in the fourth commit: 320ea80

For platform

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

cd server
git checkout c93c3464732c93c9be593a3a55b032c029c4bd6f
pwsh ./dev/generate_openapi_files.ps1

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

git status
# This should report a clean work tree

⏰ 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.

[Hinton]

I've reviewed all code except the auto generated which i've confirmed matches the output from manually running it.

[JaredSnider-Bitwarden]

Auth file change LGTM!

[sonarqubecloud]

Quality Gate passed

Issues
142 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
58.9% Duplication on New Code

See analysis details on SonarQube Cloud