Allow prefix match on program / object pin paths

[lmb]

Describe the feature you'd like supported

ebpf_get_next_pinned_program_path currently returns the next path after start_path:

ebpf-for-windows/include/ebpf_api.h

Lines 520 to 522 in 95267a5

	_Must_inspect_result_ ebpf_result_t
	ebpf_get_next_pinned_program_path(
	_In_z_ const char* start_path, _Out_writes_z_(EBPF_MAX_PIN_PATH_LENGTH) char* next_path) EBPF_NO_EXCEPT;

One interpretation of the documentation is that "next" refers to the lexicographically following / greater string:

start_path: my/pin/path/ -> next_path:my/pin/path/map

In fact, "next" refers to the order of entries in the internal pinning map, which is unspecified / implementation detail. Passing an arbitrary path as "start_path" is therefore not well specified.

This is a problem when trying to clean up all pins that share a prefix, for example to clean up after a unit test (this is what I'm trying to achieve). The only way to achieve this right now is to iterate ALL pins, which can get slow.

Another problem is that defining "next" like this means that iteration is not well defined in the presence of concurrent deletions:

char pinpath[EBPF_MAX_PIN_PATH_LENGTH] = "";
    while (ebpf_get_next_pinned_program_path(pinpath, pinpath) == EBPF_SUCCESS) {
        ebpf_api_unpin_object(pinpath, strlen(pinpath));
    }

Here pinpath is deleted, and hence the kernel side code can't find the correct entry to resume from.

Proposed solution

Change the function so that "next" has the meaning of "following in lexicographical order". This might require making the pinning table an ordered datatype.

Additional context

No response

[lmb]

• @Alan-Jowett raised the question whether /my/pin/path should return items that follow lexicographically but do not share the prefix. I think it should be prefix match + lexicographical next.
• @Alan-Jowett also asked whether we should treat directory separator specially. I think this might make sense, for example we could normalise both \ and / to a single separator. This would ease interoperability between applications using different directory separators.