Refactor and Optimize Match Resource Definition

### **Current Behavior**

Currently, to check if a resource matches a definition using capture_match_info_fn, we always need to pass a function to perform additional checks.

This causes two problems:
* The check function is called inside the capture_match_info_fn, so we cannot determine if fails on the check or matching part.

* If the caller doesn't want to perform any extra checks, they still have to pass a dummy closure.

### **Possible Solution**

Instead of calling capture_match_info_fn directly and applying the guard check function (or another function passed as a parameter) inside the function, we can change the approach. Let the capture_match_info function only handle the task of resource matching using the service request and we can create a more general function wrapper where runs the matching and check.


Also, what we could do in the routing layer is execute the check function only when capture_match_info returns true (meaning the resource definition matches) and only one time.
Then we stop the flow always but returning the resource definition only if check function returns success.

This avoid looping through all resource definitions always (if route not found or found but fails in check function), but we lose the flexibility of having multiple resource definitions with same routing configuration's but different guards (this flexibility is really needed/useful? Always routes can be defined using the join of the two defined route guards).

This change improves performance and reduces resource usage in the routing layer using early return.
It also improves abstraction and responsibility separation by avoiding the need to pass dummy closures when no check is needed.

Would be a pleasure to do my first contribution!
Kind Regards,
Manuel

Start by locating the routing layer and the capture_match_info_fn and capture_match_info call flow described in the issue, then trace how service requests, resource definitions, and guard checks interact. Clarify whether multiple resource definitions with the same routing configuration but different guards must remain supported. Done means matching and optional checking have separate responsibilities, with the guard evaluated only after a successful match.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.