Add support to be able to test the route tree using `match_pattern` and `match_name`.

[Lalit3716]

So currently the test requests does not seem to implement the match functions - match_pattern/match_name. Consider the below app having two services:

#[get("/hello/{name}", name = "greet")]
async fn greet(name: web::Path<String>) -> impl Responder {
    format!("Hello {name}!")
}

#[get("/hello/me", name = "greet_me")]
async fn greet_me() -> impl Responder {
    format!("Hi Developer!")
}

And a test like this:

    #[actix_web::test]
    async fn test_index_get() {
        let _app = test::init_service(App::new().service(greet).service(greet_me)).await;
        let req = test::TestRequest::get()
            .uri("/hello/john")
            .insert_header(ContentType::plaintext())
            .to_srv_request();

        println!("{:?}", req.match_pattern());
        println!("{:?}", req.match_name());
        assert!(true);
    }

Expected Behavior

match_pattern should print the matching route url/path, in this case: "/hello/{name}" match_name should print the given name to the service, in this case: "greet"

Current Behavior

Both match_pattern and match_name returns None.

Context

We can use these functions to test if the user has registered the services in the correct order as he/she intended and the user requests are in fact routing to correct handlers.

Currently, if user had registered the greet service before greet_me service and a user sends the request to /hello/me it will send "Hello me!`` whereas it should have returned "Hi Developer!". That's what we wanted to test, Additional Context: https://github.com/qdrant/qdrant/issues/3547.

Your Environment

• Rust Version: rustc 1.75.0 (82e1608df 2023-12-21)
• Actix Web Version: 4

[HappyPotatoman]

Hey, how about adding a clippy warning to catch and warn in cases like this.

I assume the real pain happens if the developer doesn't realize some path is unreachable due to a match all pattern matched before the target path.

[Lalit3716]

Yeah giving a warning about unreachable routes sounds good to me.

And yeah exactly this-

Hey, how about adding a clippy warning to catch and warn in cases like this.

I assume the real pain happens if the developer doesn't realize some path is unreachable due to a match all pattern matched before the target path.