Use a path string instead of a string list to encode Node paths

[r-c-n]

Currently, all Nodes have a path field that encodes the path to that node from a root node (in practice, a checkout node) as a list of strings. I don't know the reason to pick a list to encode a path, but there are certain shortcomings that come with it, the most important of which is that it severely handicaps the way it can be used in queries. That is, we can't search for nodes with a certain string in their paths because we can't express that kind of condition (match an element inside a list) in our queries.

I propose we use a more universal approach to paths and use a common slash-separated path string instead?

Pros:

• They can be properly used as query conditions
• They can carry additional information that the lists can't provide: for instance, we can encode whether a node is a leaf node or an intermediate node by having the intermediate nodes end their path string with a trailing slash ('/'). This would give us additional expressiveness in the queries for free, we'd be able to quickly identify if a node contains children nodes or if it's a leaf node.
• No loss of expressiveness or features compared to the current implementation.

Cons:

• The character used as the separator can't appear in the name of a test suite, test case, etc.

This could be done with very few code changes, a simple set of helper functions can do the work of managing this field (appending parts to the path, setting a trailing slash when adding children nodes, unpacking path parts, etc).

[nfraprado]

As discussed in Slack, due to the fact that different nodes in the hierarchy might have the same name, a regression might be created between two nodes that represent different things (eg a LAVA job and a test suite). Example: https://staging.kernelci.org:9000/viewer?node_id=6667fb443f57810c99cb7c18 . Having the feature described in this issue would allow the regression detection logic to only match nodes that happen in the same exact path, fixing the problem.