[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