MFH (r309269): use malloc()ed buffers instead of stack buffers

MFC r308806

Speed up pw operations that edit /etc/group or /etc/passwd

r285050 fixed a bug in pw that could lead to /etc/passwd or /etc/group
corruption on power loss. However, it fixed it by opening those files with
O_SYNC, which is very slow, especially on ZFS. This change replaces O_SYNC
with appropriately placed fsync()s instead, which is much faster. Using a
ZFS tmpdir, the time to run pw's kyua tests drops from 245s to 35s.

MFC r285050, r285053, r285059:

When passwd or group information is changed (by pw, vipw, chpass, ...)
temporary file is created and then a rename() call move it to official file.
This operation didn't have any check to make sure data was written to disk
and if a power cycle happens system could end up with a 0 length passwd
or group database.

There is a pfSense bug with more information about it:

https://redmine.pfsense.org/issues/4523

The following changes were made to protect passwd and group operations:

* lib/libutil/gr_util.c:
- Replace mkstemp() by mkostemp() with O_SYNC flag to create temp file
- After rename(), fsync() call on directory for faster result

* lib/libutil/pw_util.c
- Replace mkstemp() by mkostemp() with O_SYNC flag to create temp file

* usr.sbin/pwd_mkdb/pwd_mkdb.c
- Added O_SYNC flag on dbopen() calls
- After rename(), fsync() call on directory for faster result

* lib/libutil/pw_util.3
- pw_lock() returns a file descriptor to master password file on success

Differential Revision: https://reviews.freebsd.org/D2978
Approved by: re (kib), bapt (implicit agreed)
Sponsored by: Netgate

MFC: 272445,272578,273772,273779,273782,273786,273787,273791

Add a test for bug 191427 where pw(8) will go into an infinite loop
Add some tests for modifying groups
When a group is renamed then the group has been invalidated for sure.
In that case get the group information using the new name.

Fix a regression in pw usermod -G list

The user was perperly adding the to different groups from "list" but was not
removed from the other groups it could have belong to.

Do not delete the group wheel when bad argument is passed to pw groupdel -g

Check that the -g argument is actually a number, if not report an error.
This argument is converted without checking with atoi(3) later so without this
check it converts any alpha entries into 0 meaning it deletes the group wheel

Ensure pw userdel -u <invalid> do not try to remove root

Check the uid passed is actually a number as early as possible

Fix renaming a group via the gr_copy function

Add a regression test to pw(8) because the bug was discovered via using:
pw groupmod

PR: 193704 [1], 185666 [2], 90114 [3], 187189 [4]
Submitted by: Marc de la Gueronniere [4]
Reported by: az [1], sub.mesa@gmail.com [2], bkoenig@cs.tu-berlin.de [3],
mcdouga9@egr.msu.edu [4]

MFC r285050, r285053, r285059:

When passwd or group information is changed (by pw, vipw, chpass, ...)
temporary file is created and then a rename() call move it to official file.
This operation didn't have any check to make sure data was written to disk
and if a power cycle happens system could end up with a 0 length passwd
or group database.

There is a pfSense bug with more information about it:

https://redmine.pfsense.org/issues/4523

The following changes were made to protect passwd and group operations:

* lib/libutil/gr_util.c:
- Replace mkstemp() by mkostemp() with O_SYNC flag to create temp file
- After rename(), fsync() call on directory for faster result

* lib/libutil/pw_util.c
- Replace mkstemp() by mkostemp() with O_SYNC flag to create temp file

* usr.sbin/pwd_mkdb/pwd_mkdb.c
- Added O_SYNC flag on dbopen() calls
- After rename(), fsync() call on directory for faster result

* lib/libutil/pw_util.3
- pw_lock() returns a file descriptor to master password file on success

Differential Revision: https://reviews.freebsd.org/D2978
Approved by: re (kib), bapt (implicit agreed)
Sponsored by: Netgate

MFC: 272445,272578,273772,273779,273782,273786,273787,273791

Add a test for bug 191427 where pw(8) will go into an infinite loop
Add some tests for modifying groups
When a group is renamed then the group has been invalidated for sure.
In that case get the group information using the new name.

Fix a regression in pw usermod -G list

The user was perperly adding the to different groups from "list" but was not
removed from the other groups it could have belong to.

Do not delete the group wheel when bad argument is passed to pw groupdel -g

Check that the -g argument is actually a number, if not report an error.
This argument is converted without checking with atoi(3) later so without this
check it converts any alpha entries into 0 meaning it deletes the group wheel

Ensure pw userdel -u <invalid> do not try to remove root

Check the uid passed is actually a number as early as possible

Fix renaming a group via the gr_copy function

Add a regression test to pw(8) because the bug was discovered via using:
pw groupmod

PR: 193704 [1], 185666 [2], 90114 [3], 187189 [4]
Submitted by: Marc de la Gueronniere [4]
Reported by: az [1], sub.mesa@gmail.com [2], bkoenig@cs.tu-berlin.de [3],
mcdouga9@egr.msu.edu [4]