Order of auto-generated extractors not optimized

[rxdiscovery]

Hello,

While analyzing the code generated by the #[OpenApi] / #[oai] macro, I noticed that it doesn't prioritize security over other parameters, let me explain:

let's take this code as an exampe :

const CODE_EXAMPLE: fn() -> String = || "0000000000".to_owned();

const TYPE_CODE_EXAMPLE: fn() -> String = || "A2".to_owned();

const DEFAULT_TYPE_CODE: fn() -> String = || "A2".to_owned();

pub struct CityRestCtl;

#[OpenApi(prefix_path = "/city", tag = City)]
impl CityRestCtl {
    /* ----------------------------------------------------------------------------------------- */
    /// Get by code
    #[oai(path = "/:code", method = "get", operation_id = "getTest")]
    pub async fn get_test(
        &self,

        #[oai(name = "type_code", default = "DEFAULT_TYPE_CODE", example = "TYPE_CODE_EXAMPLE")]
        /// code type
        Query(type_code): Query<String>,

        #[oai(name = "code", example = "CODE_EXAMPLE")]
        /// the code
        Path(code): Path<String>,

        JwtSecurityScheme(_auth): JwtSecurityScheme,
    ) -> Result<HttpJsonResponse<CityDTO>, ApiResponseError> {
        return Err(ApiResponseError::BadRequest(PlainText("Bad request".to_string())));
    }
}

the macro will generate a code with extractors automatically;

but by analyzing the function generated add_routes() :

we can see that the order of extractors respects the order of declaration of endpoint parameters,

1. Path<String>as poem_openapi::ApiExtractor
2. Query<String>as poem_openapi::ApiExtractor
3. JwtSecurityScheme as poem_openapi::ApiExtractor

JwtSecurityScheme is in p3,

...
let p3 = match<JwtSecurityScheme as poem_openapi::ApiExtractor> ::from_request(&request, &mut body,param_opts).await {
                        ::std::result::Result::Ok(value) => value, 
                        ::std::result::Result::Err(err)if<Result<HttpJsonResponse<CityDTO> ,ApiResponseError>as poem_openapi::ApiResponse> ::BAD_REQUEST_HANDLER => {
                            let res =  <Result<HttpJsonResponse<CityDTO> ,ApiResponseError>as poem_openapi::ApiResponse> ::from_parse_request_error(err);
                            let res = poem_openapi::__private::poem::error::IntoResult::into_result(res);
                            return::std::result::Result::map(res,poem_openapi::__private::poem::IntoResponse::into_response);
                        }
                        ::std::result::Result::Err(err) => return::std::result::Result::Err(::std::convert::Into::into(err)),
                    
                        };
...

which is a safety risk and a performance problem, normally we check the Jwt token, if it's OK, we continue the analysis of the other parameters,
but since the parameter ( JwtSecurityScheme(_auth): JwtSecurityScheme) is last, the extractor is also the last to be created.

the only way to avoid this is to put this parameter just after &self, like this :

#[OpenApi(prefix_path = "/city", tag = City)]
impl CityRestCtl {
    /* ----------------------------------------------------------------------------------------- */
    /// Get by code
    #[oai(path = "/:code", method = "get", operation_id = "getTest")]
    pub async fn get_test(
        &self,
      JwtSecurityScheme(_auth): JwtSecurityScheme, // <-------------------------- !!!!!

        #[oai(name = "type_code", default = "DEFAULT_TYPE_CODE", example = "TYPE_CODE_EXAMPLE")]
        /// code type
        Query(type_code): Query<String>,

        #[oai(name = "code", example = "CODE_EXAMPLE")]
        /// the code
        Path(code): Path<String>

      ) -> Result<HttpJsonResponse<CityDTO>, ApiResponseError> {
        return Err(ApiResponseError::BadRequest(PlainText("Bad request".to_string())));
    }
}

it would be very interesting if the macro detected the presence of a "SecurityScheme", and always put it in p1 before "Path<>" and "Query<>"

(we also need to review code redundancy, for each endpoint we have the same extractors that are generated in the function add_routes() core, externalizing them and making calls would be more judicious. )

Thanks a lot.