Define whether path prefix matches are element-wise or byte-wise

[jpeach]

Gateway defines a prefix match like this:

Prefix and Exact paths must be syntactically valid:

• Must begin with the ‘/’ character
• Must not contain consecutive ‘/’ characters (e.g. /foo///, //).
• For prefix paths, a trailing ‘/’ character in the Path is ignored, e.g. /abc and /abc/ specify the same match.

But Ingress V1 says:

Prefix: Matches based on a URL path prefix split by /. Matching is case sensitive and done on a path element by element basis. A path element refers to the list of labels in the path split by the / separator. A request is a match for path p if every p is an element-wise prefix of p of the request path.

I don't recall a discussion about this, but we should discuss whether to align the Gateway prefix semantics with Ingress.

[youngnick]

I am a +1 for making these definitions line up. It makes the migration easier for users, and for Contour, we've already implemented these, so we can easily reuse code.

[hbagdi]

+1 to sticking to element-wise.

Any use-cases we know of that won't be satisfied with that approach?