MINOR: Refine route-acl rules to prevent unintended prefix matches

[fabianonunes]

Since route-acl annotated rules take precedence over others, this PR updates its behavior to ensure they do not unintentionally overwrite other rules that share the same word prefix.

For example, a rule matching the path prefix /api should not inadvertently handle requests to /apiary.

To address this, the rule { path -m beg /api } has been replaced with a alternative that validates the URL's termination, ensuring it matches only /api$ or /api/.*:

# before this PR:
use_backend app_api_http if { var(txn.host) -m str api.demo } { path -m beg /api } { ... }

# after:
use_backend app_api_http if { var(txn.host) -m str api.demo } { path -m reg ^/api($|/) } { ... }

For better maintainability, this PR also refactors the AddCustomRoute function to eliminate redundancy introduced in commit c28d620. The updated code removes repetition without add extra spaces.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[fabianonunes]

I'd like to know if there's anything I can do to facilitate the merge of this PR.

I understand that using regex might have some performance impact (though I'm not sure about this). If that's a concern, we could implement two separate rules instead:

# matches all paths that begin with `/api/`
use_backend app_api_http if { var(txn.host) -m str api.demo } { path -m beg /api/ } { ... }
# matches all requests with the exact path `/api`
use_backend app_api_http if { var(txn.host) -m str api.demo } { path -m str /api } { ... }

This approach would achieve the same goal of preventing unintended matches (like /apiary) while potentially avoiding any regex performance overhead, if that's the case. Please let me know if there are any other concerns I can address to help move this PR forward.

Regarding the failed check HAProxy check commit message, I've already added the word acl to the dictionary and force-pushed, but the job hasn't been re-executed yet.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.