cred: 'kern.ngroups' tunable: Limit it to avoid internal overflows

[olce]

Summary

As the comment introduced with the tunable said (but the code didn't
do), make sure that 'ngroups_max' can't be INT_MAX, as this would cause
overflow in the usual 'ngroups_max + 1' computations (as we store the
effective GID and supplementary groups' IDs in the same array, and
'ngroups_max' only applies to supplementary groups).

Further, we limit the maximum number of groups somewhat arbitrarily to
~17M so as to avoid overflow when computing the size in bytes of the
groups set's backing array and to avoid obvious configuration errors.
We really don't think that more than ~17M groups will ever be needed (if
I'm proven wrong one day, please drop me a note about your use case).

While here, document more precisely why NGROUPS_MAX needs to be the
minimum value for 'ngroups_max'.

[mhorne]

You are too kind to the foot-shooters ;)

[olce]

In D46913#1078959, @mhorne wrote:

You are too kind to the foot-shooters ;)

Yeah, I don't expect anyone to ever use a value close to INT_MAX, which in any case would probably cause memory problems in some places (e.g., NFS). But it didn't cost much to add that extra if.

The real value of this commit, IMO, is the existing comment's expansion about why ngroups_max cannot be smaller than NGROUPS_MAX with a reference to the standard.

[olce]

Be stricter for the maximal value of kern.ngroups (see the updated commit message and inline comments).