Fix building when HOST is set (e.g. to hostname)

[adaugherity]

I tried building this on openSUSE Leap 15.2, and there were several failures related to reallocarray, UID_MAX, GID_MAX, setresuid, setresgid, and execvpe. Diving into to reallocarray(), I noticed configure reported it as being present, but the man page indicates it requires _GNU_SOURCE. (I have glibc 2.26, which lacks the reference to _DEFAULT_SOURCE.)

While working up a patch for that, I discovered that configure should've already set both _GNU_SOURCE and _DEFAULT_SOURCE on Linux, but was not doing so. In fact it was setting OS_CFLAGS=-D__earth.lan__, which looked suspiciously like part of my internal domain! I traced that here, and sure enough, my system has $HOST set to my FQDN (e.g. frodo.middle-earth.lan).

[open]SUSE's /etc/profile sets HOST=$(uname -n) (aka hostname), and has done so since 2010 according to the git history. This completely breaks everything the configure script derives from $HOST.

As a naïve fix, I've renamed the HOST variable to HOSTCC, and that fixed all the build issues. Perhaps doing something like unset HOST BUILD TARGET to force the user to use the configure options --host= etc. would be preferable, but I don't know...

---

Unrelated: Linux has long supported 32-bit UID/GIDs (which might be encountered in domain environments, e.g. sssd), but you default to UID_MAX=65535. I could of course call ./configure --uid-max=4294967295 --gid-max=4294967295, but I feel like I shouldn't have to. Does anything still use 16-bit UIDs these days?

(Actually --gid-max doesn't work, as due to a typo that sets UID_MAX again. Oops!)

Thanks for your work porting doas and for trying to take security seriously!