Revert previous. Explicitly load the value of npf or pf

Load rc configuration based on rcvar, not name, so that correct settings
in /etc/rc.conf.d are loaded.

Usually this does not matter as rcvar and name are set to the same value.
For pf_boot and npf_boot, rcvar is set to pf and npf respectively.

Prior to the change, if:
rc.conf contains nfp=YES
rc.conf.d/npf does not exist

Then:
/etc/rc.d/npf_boot rcvar
outputs:
# npf_boot
$npf=YES

If:
rc.conf contains npf=NO (or is not set)
rc.conf.d/npf contains npf=YES

Then:
/etc/rc.d/npf_boot rcvar
outputs:
# npf_boot
$npf=NO

This means that in the latter case, at boot time the npfctl start command
is never run and the firewall is not operational.

Rename MOUNTCRITLOCAL to CRITLOCALMOUNTED to avoid a name collision
on case insensitive file systems

Split the local disk availability step into two phases to allow scripts
that pre-populate parts of the system (e.g. a tmpfs based /var) an
easy place to plug in like:

# REQUIRE: mountcritlocal
# BEFORE: MOUNTCRITLOCAL

This also cleans up the existing special handling a bit by separating it
into new scripts. All later scripts now depend on MOUNTCRITLOCAL.
Discussed on tech-userlevel some time ago.

No need to empose the script to be runnable during boot time, it prevents the
script from wroking if the system is booted into single user mode & then
moved onto multi-user mode.

Reported by <pgoyette> for NPF but the issue is there in PF too.

branches: 1.4.50; 1.4.52;
Add "bootconf" to REQUIRE: lines which had beforenetlkm
since removed beforenetlkm required bootconf.

Remove LKMs and switch to the module framework, pass 1.

Proposed on tech-kern@.

branches: 1.2.12;
* Add a stop_boot() function in rc.subr, to terminate a multi-user boot
by killing the parent process. The parent's PID is saved in $RC_PID.
* In all rc.d/* scripts that previously tried to stop the boot,
replace in-line code with "stop_boot".
* Document this.

This should fix PR 29822.

branches: 1.1.2;
pf needs to be started after the network is up, because some pf rules
derive IP address(es) from the interface (e.g "... from any to fxp0").
This however, creates window for possible attacks from the network.

Implement the solution proposed by YAMAMOTO Takashi:
Add /etc/defaults/pf.boot.conf and load it with the /etc/rc.d/pf_boot
script before starting the network. People who don't like the default
rules can override it with their own /etc/pf.boot.conf.
The default rules have been obtained from OpenBSD.

No objections on: tech-security