btf, linker: resolve kfuncs by essential name when exact match fails - #2098

Summary

Fixes #2057. When a kfunc call can't be resolved by its exact name in
the kernel's BTF, retry using the name with its ___ flavour suffix
stripped (its "essential name"), matching the same "ignored suffix
rule" already used for CO-RE relocations.

This lets a BPF program declare multiple ___-suffixed variants of a
kfunc whose signature has changed across kernel versions (e.g.
foo___old, foo) and have the variant matching the running kernel
resolve automatically, instead of only ever resolving kfuncs with an
exact name match.

What was already there vs. what this adds

While tracing this, I found the signature-compatibility half of the
issue ("ensure its function signature is the same") is already
implemented: fixupKfuncs in linker.go calls
btf.CheckTypeCompatibility on whatever target is resolved, before
using it. So the only missing piece was the name resolution itself,
which was doing an exact match only (findTargetInKernel →
Spec.TypeByName, no suffix handling).

This adds btf.EssentialName, an exported wrapper around the
existing internal newEssentialName/essentialNameLen CO-RE logic
(so the suffix-stripping rule itself isn't duplicated), and uses it
as a fallback in fixupKfuncs specifically — not in
findTargetInKernel itself, since that helper is shared with program
attach-target and struct_ops lookups, where fuzzy suffix matching
would be an unwanted, silent behavior change.

Testing

• go build ./..., go vet ./..., gofmt -l all clean.
• Added TestEssentialNameExported for the new exported wrapper. The
  suffix-stripping logic itself already has thorough edge-case
  coverage via the existing TestEssentialName.
• Could not exercise the fixupKfuncs retry path end-to-end: that
  requires loading a program against real kernel BTF containing a
  kfunc with multiple versioned signatures, and this dev environment
  has neither CAP_BPF nor such a kfunc available to test against.
  Marking as draft for that reason — happy to add an integration test
  if a maintainer can point me at a suitable existing kfunc/kernel
  fixture, or if there's a preferred way to fake this in the test
  suite.

Generative AI disclosure

Per the Cilium Generative AI policy: I used Claude (Anthropic) while
preparing this submission. It helped trace where kfunc resolution
actually happens in the codebase, confirmed the signature-compatibility
check already existed, and helped scope the fix to avoid changing
shared lookup behavior used by other callers. I reviewed and
understood the resulting design and code before submitting, and I'm
happy to discuss any part of it further during review.

🤖 Generated with Claude Code