Revisiting ABI_VERSION handling policy

[Felix Fietkau]

Hi,

I just wasted a few hours of debugging on an issue that turned out to be
wolfssl ABI breakage related.

At first I thought it was the version bump. While the commit that
updates wolfssl claims that the ABI didn't change, a quick look at
https://abi-laboratory.pro/index.php?view=timeline&l=wolfssl indicates
that this isn't true and the ABI did change after all.

When I looked into the details of the ABI change, I found out that this
wasn't the cause of my breakage (I had already cleaned my hostapd build
after updating wolfssl), but there is something even nastier lurking
here: the ABI isn't just affected by the version bump, but by wolfssl
configuration changes as well. There are plenty of #if statements inside
structs like Aes which are sometimes declared on-stack in hostapd, many
of which are affected by the OpenWrt configuration for wolfssl.

I think it's very likely that I've been affected by similar breakages in
the past, but I can't be absolutely sure now, because I didn't have the
time to investigate back then and a lazy make clean made things work again.

Either way, this whole ordeal caused me to rethink Jo's commit
"packages: set more explicit ABI_VERSION values"

The goal of reducing unnecessary build churn makes perfect sense to me,
but I think we need to reconsider the trade-off we're making here, and
the failure modes of each option.

I believe that having to manually consider whether the ABI changed when
updating a package comes with a nasty foot-gun that can deliver very
subtle and hard to debug failure cases.
In my case, hostapd worked just fine and wpa_supplicant was crashing due
to a stack overflow whenever I turned on 802.11w on a client interface.

Stuff like this makes our trade-off seem very asymmetric to me...

To fix this situation, I would like to switch wolfssl and maybe a few
other packages prone to ABI breakage back to version based ABI_VERSION.
At least wolfssl also needs a short suffix generated from config vars.

If we want to reduce build churn, we should find a way to automate
setting the ABI version, since clearly our package maintainers + review
process cannot (and in my opinion also should not) be trusted with this
extra responsibility.

Maybe we can replace it with a hash of all installed header files. This
might be a better way to resolve cases like this wolfssl instance, but
we likely will still be rebuilding dependent packages on most updates.

Thoughts?

- Felix