Resolve kfuncs based on essential name

[dylandreimerink]

As it stands we only ever resolve kfuncs when their name in the kernel matches exactly with the name in a program we are trying to load. However, there is a feature in BTF/CORE called the "ignored suffix rule" which allows users to add a suffix separated by three underscores (___), and have them be ignored during type matching.

The reason for this feature is that it allows a user to define multiple variants of a type or kfunc in this case. For example the scx_bpf_reenqueue_local was modified in kernel 6.19, going from returning a u32 to returning void. A valid change since kfuncs do not have the same stability guarantee as old school helper functions.
In order for a user to write a single program that works on kernels before and after the change we have to be able to discover which version is available and use the correct one, this looks like:

u32 scx_bpf_reenqueue_local___v1(void) __ksym __weak;
void scx_bpf_reenqueue_local___v2___compat(void) __ksym __weak;

static inline void scx_bpf_reenqueue_local(void)
{
	if (bpf_ksym_exists(scx_bpf_reenqueue_local___v2___compat))
		scx_bpf_reenqueue_local___v2___compat();
	else
		scx_bpf_reenqueue_local___v1();
}

Original from https://elixir.bootlin.com/linux/v7.1.3/source/tools/sched_ext/include/scx/compat.bpf.h#L396

The expected result is that on pre-6.19 kernels the ___v1 symbol is resolved and the ___v2___compat version is unresolved, so bpf_ksym_exists returns false and the ___v1 path is always chosen. On newer kernels the v2 kfunc is resolved and thus called.

This PR makes the needed changes.

Fixes: #2057

[dylandreimerink]

While working on this I had some doubts about the best way to go about the changes in the btf package. We can add additional "fuzzy" methods or we can do a breaking API change and allow specifying exact or fuzzy matching via an argument.

I implemented both, the second commit implements it with additional methods, and the third commit refactors it to be breaking. That way we can get a feel for what one or the other would look like. I can squash or drop commits depending on which we like better.

Please leave your feedback.

[ti-mo]

Thanks for the proposals! If you ask me: let's pick neither solution. Let's keep essential names an implementation detail, as they don't seem useful outside the scope of conflict resolution for ksyms within the loader. I can't really come up with use cases beyond ELF loading. I don't think we should add another flavor (*EssentialName) of query methods, that doesn't make things clearer IMO.

I find it rather surprising/problematic that the existing implementation calls newEssentialName() unconditionally, as it's not documented anywhere. Your instinct to make exact-matching explicit is a good one; but let's go the opposite way: move newEssentialName() to the root package and call it only where we expect to resolve type flavors (all the sites where you've specified , false in the 3rd commit).

This way, it becomes explicit, we don't break API (although it's technically a breaking change we should document), and we don't unnecessarily complicate Spec querying.

Alternatively, we export btf.NewEssentialName, but I'd rather see users come forward with concrete reasons for that before we pull the trigger. In the meantime, the workaround is splitting a string on triple-underscore, not exactly ground-breaking stuff.

[dylandreimerink]

@ti-mo made the changes, this should be closer to your suggestion.