Support Nested Tracks

[gingerwizard]

Currently tracks can be nested and most functions work. This isn't by design e.g.

Consider the folder hierarchy

rally-tracks
  observability
    logging
    metrics
    apm

Most rally commands would work (including the ability to use the track) with the track parameter e.g.

--track="observability/logging"

Some commands such as esrally list tracks will not.

Do we want to support nested tracks? If so, where are the current deficiencies in support?

[gingerwizard]

@danielmitterdorfer id like to address this if possible. Happy to take but unclear on the requirements. Do we want to support to just one level i.e. like above or potential infinite hierarchies? The latter seems possible but i'm not sure if its practically worth the potential challenges and something we'd want to encourage.

[danielmitterdorfer]

I wouldn't necessarily restrict the nesting level. I agree that infinite hierarchies are probably not a good idea but I am not certain whether e.g. two levels would be a good idea or not? But I think we'll see once we get more experience with the feature.

[gingerwizard]

Maybe we support infinite hierarchies in theory but restrict the recursive depth to a hidden config parameter. We can adjust or remove as we feel confident regards how this feature will be used?

[danielmitterdorfer]

The implementation should actually be rather targeted in scope. It is sufficient to modify GitTrackRepository, as this handles --track. The track resolution logic is implemented in the track_names property. Currently, this logic does not descend recursively. If we change the logic such that it descends until it finds a track file (i.e. track.json) and produces track names where directories are separated by a path separator (/), then everything else should work out of the box.