Use sysctl value for localbase in rc files

[se]

Summary

With the value of _PATH_LOCALBASE available as sysctl variable user.localbase, this value can be used to replace literal occurences of /usr/local in /etc/defaults/rc.conf

This is meant as just a proof of concept, e.g. there might be a better name for the variable _localbase

Test Plan

Apply patch to rc.conf and verify that all variables are initialized to unchanged values.
Apply patch to rc and verify that all variables are initialized to unchanged values.
Apply the patch from D27009 and verify that all variables are initialized to unchanged values.
Finally, on a system built with a non-default value of _PATH_LOCALBASE in paths.h, the localbase path is correctly used in variables defined in /etc/rc.conf/defaults to match the non-default LOCALBASE

[scottl]

I was about to upload a different patch that uses the environment. I'd rather take it in that direction since there's already a strong precedence for acquiring LOCALBASE from the environment. Need to finish the man page then I'll upload it. Please hold off on this.

[imp]

Env vars are good for per user things... but less good for system wide things. It would be better to honor it if set, but populate it from the sysctl. Rc.conf variables also aren't all caps or apply to multiple scripts... something to consider. Also, for setuid binaries (nor relevant here) you can't use env cars, so you need some fallback...

[se]

In D27014#602641, @scottl wrote:

I was about to upload a different patch that uses the environment. I'd rather take it in that direction since there's already a strong precedence for acquiring LOCALBASE from the environment. Need to finish the man page then I'll upload it. Please hold off on this.

This was only a suggestion that works, but might not the best way to ahead - I had not intention to commit it as is.

But I'm not convinced of the usefulness of an environment variable for this purpose, since I consider LOCALBASE a system setting, not a per-user setting.

And there definitely are security implications, not only for SUID programs, to trust environment variables that are used to control configuration and possibly authentication features.

My idea is to have a way to easily change the LOCALBASE compiled into programs (already done with _PATH_LOCALBASE, except for contrib sources, which I did not touch to prevent MFV conflicts).
This value is currently compiled in, but I can imagine it becoming a loader tunable or even a writable sysctl variable and I am ready to implement either of these changes, but not convinced that it is the correct next step.

My suggestion for the next step is to have this LOCALBASE become accessible to configuration files and scripts.
If it will later be made boot-time or run-time configurable, this should be transparent to those scripts (but I really do not see much value in making it run-time configurable, but I do see security issues in that case that need to be considered and resolved, first).

Therefore, I really prefer the sysctl over an environment variable (which will need source changes to become effective in binaries, several of them in contrib).
The sysctl value is provided by the C library, it does not require a system call (unless the value is made boot-time or run-time configurable with a "real" sysctl variable maintained in the kernel instead of in libc).

[scottl]

I think I have a way for us to converge on our strategies. Please see https://reviews.freebsd.org/D27022