feat: add routeBind support to Giraffe.EndpointRouting

[AugustoRengel]

Description

This PR extends the existing routeBind support from the Giraffe.Routing module to also work with Giraffe.EndpointRouting, while preserving the same syntax.

A new test was added to EndpointRoutingTests.fs to validate the routeBind behavior when using endpoint routing.

How to test

1. Define an endpoint using routeBind, for example:

open Giraffe.EndpointRouting

[<CLIMutable>]
type Name = { First: string; Last: string }

[<CLIMutable>]
type Person = { Name: Name; Age: int }

let endpoints: Endpoint list =
    [
        GET [
            routeBind<Person>
                "/p/{Name.First}/{Name.Last}/{Age}"
                (fun (person: Person) ->
                    text ($"Name.First: {person.Name.First}, Name.Last: {person.Name.Last}, Age: {person.Age}")
                )
        ]
    ]

2. Run the application.
3. Send a request such as: GET /p/John/Doe/32
4. Verify that:
   • The request is successfully routed.
   • The handler receives a Person instance with First = "John", Last = "Doe", and Age = 32.

Also, a new test was added to EndpointRoutingTests.fs

Related issues

Fixes #708

[AugustoRengel]

The documentation mentions that endpoints ending with a trailing "/" can be covered by adding the "(/?)" regex, for example: routeBind<Blah> "/p/{foo}/{bar}(/?)" blahHandler.
However, this is not necessary when using Giraffe.EndpointRouting, as ASP.NET Core already handles optional trailing slashes.
Therefore, this part of the documentation should be updated accordingly. I will do so once I have a more complete understanding of the exact behavior.

[AugustoRengel]

I could not find any explicit mention of this behavior in the documentation, but after reviewing the source code it appears that the request path is split into segments and empty segments are ignored.
The class responsible for this behavior seems to be DfaMatcher.

Based on this, I am going to update the documentation to confirm that no special handling is required for a trailing “/” when using Endpoint Routing. Please let me know if I am missing something.

[64J0]

Great PR @AugustoRengel, thanks for this contribution!
It's fine to add this new handler to the EndpointRouting module, I think.

[64J0]

After taking a better look at the code.

[64J0]

Perhaps it's better to not return this RequestErrors.BAD_REQUEST "Failed to bind route parameters" message if the parse operation fails.

Instead, we need to just keep going, testing other routes, and eventually using the error handler specified by the client.

[AugustoRengel]

I replaced the error with skipPipeline, which allows the request to flow to the next handler, but it does not switch to another endpoint because the model parsing happens after endpoint selection.

To achieve the desired behavior, the model parsing would need to run before the endpoint selection phase. Based on the ASP.NET Core routing pipeline, this seems only possible by using a custom MatcherPolicy.

If there is any alternative or recommended approach to achieve this, please let me know if I am missing something.

[64J0]

Just thinking out loud.

Something we do in other places of the project is to let our clients define a special error handler.

For example: #691.

Perhaps it makes sense to use this approach here.

Anyway, we can add this optional error handler later.

[64J0]

Adding @nojaf and @TheAngryByrd for additional review and feedback.

[nojaf]

Looks good to me from afar.