shm: Respect PROT_MAX when creating private mappings

[markj]

Summary

We were previously unconditionally adding PROT_WRITE to the maxprot of
private mapping (because a private mapping can be written even if the
fd is read-only), but this might violate the user's PROT_MAX request.

While here, rename cap_maxprot to max_maxprot. This is the intersection
of the maximum protections imposed by capsicum rights on the fd (not
really relevant for private mappings) and the user-required maximum
protections (which were not being obeyed). In particular, cap_maxprot
is a misnomer after the introduction of PROT_MAX.

Add some regression test cases. mmap__maxprot_shm fails without this
patch. I'm not really sure where best to put them, but it's not
terribly important.

Note: Capsicum's CAP_MMAP_W is a bit ambiguous. Should it be required
in order to create writeable private mappings? Currently it is, even
though such mappings don't permit writes to the object referenced by the
fd.

Reported by: brooks
Fixes: c7841c6b8e41 ("Relax restrictions on private mappings of POSIX shm objects.")

[brooks]

sys/kern/uipc_shm.c

1684–1686

I guess you could also write this as

maxprot |= (VM_PROT_WRITE & max_maxprot);

Not sure if that's better or worse.