[Rust-Axum][Breaking Change] Implement a customizable error handler

[Victoria-Casasampere-BeeTheData]

This PR implements a way to handle errors that are not handled in the API implementations with the creation of a new ErrorHandler trait. This is beneficial for dealing with unknown possible errors, as well as dealing with the repetitive code that comes from manually handling recurring errors between multiple different endpoints.

The breaking changes are minimal and unlikely that they will affect people. These are:

• The server implementation struct now must be Send + Sync + 'static
• The server implementation must implement the trait crate::apis::ErrorHandler

The default implementation sets the error type to () / unit, this makes users migrating to the newer version to only be required to add the line impl data_models::apis::ErrorHandler for ServerImpl {} to complete the migration.

The error handler itself defaults to logging the returned error with its Debug implementation on the error log level. Users that wish to use their own error type only need to change the Result::Err return type of the methods in the API traits implementations, as well as specify the same error type as the generic type of the ErrorHandler trait being implemented in the server implementation.

// As an example
#[derive(Debug)]
pub struct CustomError;

#[derive(Debug, Clone)]
pub struct Api;

impl openapi_generated::apis::ErrorHandler<crate::CustomError> for Api {}

#[async_trait::async_trait]
impl openapi_generated::apis::default::Api<crate::CustomError> for Api {
    async fn endpoint_v1(
        &self,
        _method: Method,
        _host: Host,
        _cookies: CookieJar,
    ) -> Result<EndpointV1Response, crate::CustomError> {
        unimplemented!()
    }
}

# Command used to update the samples
mvn clean &&
./bin/generate-samples.sh bin/configs/manual/rust-axum-* &&
mvn integration-test -f samples/server/petstore/rust-axum/pom.xml

PR checklist

• Read the contribution guidelines.
• Pull Request title clearly describes the work in the pull request, and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community.
• Run the following to build the project and update samples:

  ./mvnw clean package || exit
  ./bin/generate-samples.sh ./bin/configs/*.yaml || exit
  ./bin/utils/export_docs_generators.sh || exit
  

  (For Windows users, please run the script in Git BASH)
  Commit all changed files.
  This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
  These must match the expectations made by your contribution.
  You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java*.
  IMPORTANT: Do NOT purge/delete any folders/files (e.g. tests) when regenerating the samples, as manually written tests may be removed.
• File the PR against the correct branch: master (upcoming 7.x.0 minor release - breaking changes with fallbacks), 8.0.x (breaking changes without fallbacks)
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

@wing328 @linxGnu

[tanadeau]

Can this get added to the 7.12.0 milestone? I'd love to use this.

[linxGnu]

@Victoria-Casasampere-BeeTheData
Thank you so much for making the PR. And I am sorry for late reply due to lunar new year.

I have one concern here:

• How could user really handle the Error without some useful information (e.g URL Path, URL Params, Claims (to know who did this), etc)?

In this way, it would be the best if could include those info to ErrorHandler trait

[Victoria-Casasampere-BeeTheData]

How could user really handle the Error without some useful information.

This is not something that I needed available on my use case, so did not consider it, but I can see how having that information can be useful. I will add some additional arguments with that information to the trait method.

[Victoria-Casasampere-BeeTheData]

@linxGnu The error handler now has access to the Method, Host and CookieJar, every other parameter is way too endpoint specific, and errors that depend on knowing that data should be handled on the endpoint itself rather than the global error handler. For the purposes of error logging, this information is enough, as the additional data can be logged via instrumenting by the user, and can be looked back to when an error log pops up, as they would both share the same method, host and cookies.
One thing I don't like is that the 3 parameters need to be cloned, as making them references in the API method would be a massive breaking change.
Adding the claims to the error handler would also require for the Claim type to be Clone, or passed by reference rather than moved, something users may not want, or could even have, and the complexity of adding the generic type for the claims in the error handled is beyond me.