Parsing /proc/config.gz is fragile (it may be compiled out or live in /boot, which may not be mounted) and somewhat expensive. There are a few approaches and strategies to obviate the need to parse kconfig, in order of preference.

1. Ask for forgiveness, not permission. Keep the code simple by attempting the newest behaviour, and falling back to older behaviour if the new thing is not available. Return clear errors.
2. If the kernel doesn't provide clear error output in the face of a failure (it often doesn't..), execute a known-working feature probe on the error path to confirm a particular feature is not supported.
3. Preemptively check feature probes ahead of time. If the above two aren't possible, e.g. probe output needs to be provided as configuration to a Bash script where error handling is painful.

A certain kconfig value being specified doesn't mean a given behaviour is implemented/supported. Distro kernels are funky. Users might run a particular combination of kconfig flags that invalidate some of our assumptions, and don't pop up in distro kernels.

Areas of focus are ProbeManager.GetRequiredConfig() and ProbeManager.GetOptionalConfig().

On a technical level, (almost) all things can be probed, but we might need to come up with tooling to make it easier. For example, CONFIG_NET_{SCH,CLS}_* can be probed by creating tc hierarchies in a throwaway netns, but we should make our lives as easy as possible by providing some reusable building blocks that make porting other (and future) probes less painful.

Supersedes #20701.