Path patterns may include arbitrary nested groups, delimited by '{' and
'}', up to a limit on the total number of groups. In order to compare
the precedence of path patterns which match a given path, these path
patterns must be expanded until no groups remain, and thus the
particular group-free patterns which was resolved from the original
patterns when matching the path can be compared.

Signed-off-by: Oliver Calder <[email protected]>

Rather than separately validate and expand path patterns, storing the
result as a list of expanded patterns, parse a pattern into a
PathPattern type, which can dynamically render expanded path patterns as
needed with minimal overhead.

When path patterns are received from prompting clients, path patterns
can be unmarshalled and automatically validated, and any future use of
the pattern in-memory can use the pre-parsed PathPattern to iterate
through expanded path patterns without needing to explicitly expand and
store all path patterns.

Additionally, the new PathPattern type should be used in Constraints in
place of the old path pattern string.

Signed-off-by: Oliver Calder <[email protected]>

Rather than keep separate stacks for the sequences and paths which the
parser is currently inside, instead keep a single stack, to which the
existing sequence and a new group is added whenever a '{' rune is
encountered.

Then there is no need to no need for a variable to hold the current
group, peeking the stack yields the most recent group, to which the
current sequence can be added whenever a ',' or '}' is encountered.

When a '}' is encountered, the most recent group is popped off the
stack, the current sequence is added to it (completing the group), and
then the previous sequence is popped off the stack and the completed
group is added to it. From there, that previous sequence is now
considered the current sequence until another '{' is encountered.

Signed-off-by: Oliver Calder <[email protected]>

Signed-off-by: Oliver Calder <[email protected]>

Signed-off-by: Oliver Calder <[email protected]>

Signed-off-by: Oliver Calder <[email protected]>

…erns

Co-authored-by: Oliver Calder <[email protected]>
Signed-off-by: Oliver Calder <[email protected]>

Signed-off-by: Oliver Calder <[email protected]>

Signed-off-by: Oliver Calder <[email protected]>

Signed-off-by: Oliver Calder <[email protected]>

Signed-off-by: Oliver Calder <[email protected]>

Signed-off-by: Oliver Calder <[email protected]>

Signed-off-by: Oliver Calder <[email protected]>

Signed-off-by: Oliver Calder <[email protected]>

…token

Signed-off-by: Oliver Calder <[email protected]>

Signed-off-by: Oliver Calder <[email protected]>

…uration

Signed-off-by: Oliver Calder <[email protected]>

Signed-off-by: Oliver Calder <[email protected]>

Signed-off-by: Oliver Calder <[email protected]>

Signed-off-by: Oliver Calder <[email protected]>

Signed-off-by: Oliver Calder <[email protected]>

Also improved naming and documentation.

Signed-off-by: Oliver Calder <[email protected]>

…te naming

Signed-off-by: Oliver Calder <[email protected]>

Add a reference to the `renderNode` used to generate a given
`variantState` to that state itself. This allows methods on
`variantState` to be called without needing to pass as a parameter the
same `renderNode` which was used to generate the `variantState`.

Also, move the `Render` function to be a method on `variantState`
instead of `renderNode`. This makes sense semantically, since we render
particular variants, rather than nodes themselves, and makes sense
ergonomically since we now have a reference to the `renderNode` within
each `variantState`, so there is no need to pass parameters around for
nodes and variants which are required to be associated anyway.

Signed-off-by: Oliver Calder <[email protected]>

Signed-off-by: Oliver Calder <[email protected]>

Signed-off-by: Oliver Calder <[email protected]>

…s are exhausted

Signed-off-by: Oliver Calder <[email protected]>

…files

Signed-off-by: Oliver Calder <[email protected]>

Signed-off-by: Oliver Calder <[email protected]>

Add comment as such to the `literal` type definition, and have
`literal.NextVariant` return length 0 to make it consistent with other
`variantState` types.

Signed-off-by: Oliver Calder <[email protected]>

Signed-off-by: Oliver Calder <[email protected]>

Signed-off-by: Oliver Calder <[email protected]>

Signed-off-by: Oliver Calder <[email protected]>

Signed-off-by: Oliver Calder <[email protected]>

…dering

Signed-off-by: Oliver Calder <[email protected]>