fix: httpRoute.match.prefix does not need to end in '/'

[conorevans]

Issue #, if available: #712

Description of changes: Remove obligation for httpRoute.match.prefix to end in / - this does not match API behaviour.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[conorevans]

@BennettJames @ysdongAmazon can you take a look here please?

[ysdongAmazon]

Checked the suffix pattern only exist under gateway route validation.
In our gateway route console and SDK, true, gateway route mentioned as prefix routing instead of path-based routing. Waiting for the team to confirm if it needs to be aligned with the SDK.

I suppose the original author was trying to ensure consistency in path routing:
Prefix routing: consider two routes, one with prefix /product and another with prefix /product-special. If a request comes in with path /product-special/1234, both routes will match the request, because both prefixes are present in the path. This creates ambiguity about which route should process the request.

Path-based routing: enforced convention is applied and routes are defined with prefixes /product/ and /product-special/. With this convention, a request with path /product-special/1234 would only match the second route, eliminating the ambiguity.

[ysdongAmazon]

Triggered unit test workflow.

aws-app-mesh-controller-for-k8s/webhooks/appmesh/gatewayroute_validator_test.go

Line 365 in dc9a5f2

wantErr: errors.New("Prefix to be matched on must start and end with '/'"),

also need to be modified

[conorevans]

I suppose the original author was trying to ensure consistency in path routing:
Prefix routing: consider two routes, one with prefix /product and another with prefix /product-special. If a request comes in with path /product-special/1234, both routes will match the request, because both prefixes are present in the path. This creates ambiguity about which route should process the request.

I can see that, but it breaks a very standard case, which is just a simple /something route. Even if I don't have /something-else, then I can't use /something because it isn't /something/. When you consider that someone in that case could simply use HttpPathMatch, I don't think this safeguard makes sense. Additionally, you could even use priority on the route even if you wanted to use Prefix, e.g. Prefix /something-else with priority 1 and Prefix something with priority 2, to ensure it's evaluated first.

Will fix the unit test tomorrow!

Thanks for looking @ysdongAmazon 😄

E: I've unblocked myself using path btw, which can be regex: /myprefix$

[conorevans]

@ysdongAmazon committed the test fix!