LD_PRELOAD for Go Runtime on aarch64

ld-preload-go-runtime-aarch64.txt

The workaround for this was to set LD_PRELOAD if libsuseconnect.so was
found, but that causes new problems: This is inherited by child
processes, and now every binary started from YaST also gets this
LD_PRELOAD, so they are now also force linked to libsuseconnect.so.

YaST uses external programs extensively; among lots of other things,
for storage probing. That means that in many cases, storage probing
now fails because of this; mostly due to out of memory because
libsuseconnect.so (and the Go runtime libs that it uses?) consumes a
lot more RAM.

Not only are we always on the verge of OOM anyway (and we are at the
end of the food chain after the kernel, kernel modules, kernel
firmware, glibc, libQt and dozens of others), but who knows what other
problems this causes. This needs to stop.

It has been suggested that we should clean up LD_PRELOAD again after
the YaST start. But after an internal discussion, we decided against
that: It would be adding a hack on top of a hack; a workaround for a
workaround. And that might create even more problems.

The original problem appears in a low-memory scenario only on aarch64;
and now the first hack spread the problem to other architectures as
well.

This clearly needs a real solution, not adding hacks on top of
hacks. The original problem has been known since early 2019; it even
made it to Stack Overflow, where they suggest do set LD_PRELOAD as a
workaround.

After almost 3 years (maybe longer), there must be a real fix for
this. It really can't be an acceptable solution to spread those
workarounds all over all kinds of software; other projects will have
the same problem as well.

LD_PRELOAD is a debugging tool for desperate situations, a last-ditch
effort; it can't be the regular way to go. But recommendations on the
web seem to indicate just that for the aarch64 platform.

It doesn't help the Open Source world if we keep fighting the symptoms
and disguise the real problem; this basically forces everyone who ever
uses any Golang-based lib to do the same hacky approach, and most of
them won't even be aware of follow-up problems for child processes.

That is why we are going to revert the LD_PRELOAD change. This needs a
true fix.