Sorting request paths tree by hierarchy

Description

Currently using Proxyman 3.11.0

Hi there! 🙂
Coming from being a long time Charles user and trying to convert myself to Proxyman, I find it a bit hard to get accustomed to how Proxyman sorts incoming requests in the tree view once you expand below the Domains level.

Proxyman seems to only allow Alphabetical sorting option for Domains and Apps but no sorting options for tree structure inside the domain name itself at the moment.
From my understanding, incoming requests tree is always sorted by the time of first request for each individual network path? At least I was not able to find any way to rearrange this in some way 🤔
Also, if your REST API path can represent an actual endpoint and have more nested endpoints inside, for example:

• https://<my_host>/api/<path_1>
• https://<my_host>/api/<path_1>/<path_2>

These are always grouped as one single > path_1 node, which could be a bit confusing with more complex APIs when you deal with a lot of requests. Attached a screenshot to hopefully explain better what I try to say 😅

For comparison, Charles arranges the tree structure in a (subjectively) more intuitive way:

• any nodes that have any children are grouped on top, separately from the nodes representing actual callable endpoints
• any nodes that represent callable endpoints shown after all the nodes that have more nesting
• if your REST API path segment can represent both: an actual endpoint and have more nested endpoints inside - they are also separated in the tree structure

This feels a bit more natural, similar to "sort by kind" in Finder, when your folders would come on top, before individual files. Likewise for Windows navigation style, I think.

Why this feature/change is important?

Having more options to sort incoming traffic in a more structured way could really help and speed up inspecting the mobile app traffic during testing / debugging in more complex scenarios.

Start by reproducing the request tree behavior described for Proxyman 3.11.0 and compare it with the attached screenshots and Charles's hierarchy. The work is done when nested path nodes are visibly separated from callable endpoints and the requested hierarchy-based sorting behavior is available for complex API paths.