config-linux: Allowed values for rootfsPropagation (include r* forms)?

[wking]

The last time we touched the rootfsPropagation values was #770 (v1.0.0-rc6~97^2). However, the current wording:

Its value is either slave, private, shared or unbindable.

is troublesome. The currently lack of RFC 2119 keywords means it's not actually imposing a conformance requirement on either runtimes or configurations, even though “value is” sounds pretty unambiguous and we're (erroneously?) requiring for those values in our JSON Schema since #775.

And runc appears to extend that list of valid values to support the r* forms (e.g. rslave). Runtimes are allowed to extend lists of valid values (and even currently allowed to reduce lists of valid values, #813), so that would be fine even if the spec had MUST language for these values. But I expect we want to allow access to those r* settings from a valid config. Can we (in 1.1?) either:

a. Extend this list to include the r* forms, and then keep chugging along if/when the kernel adds new values, or
b. Drop our local list of allowed values, and just punt folks to external documentation (e.g. the “Shared subtree operations” section of mount(8))?

(b) is difficult with our locally-defined strings (e.g. rshared is MS_SHARED | MS_REC by the time it hits a mount(2) syscall), but defining translation rules should be possible. If we go with (a), it would be nice to have a table in the spec like the one I floated for mounts[].options in #771. That table includes entries for all of the kernel's current mountflags (including the propagation ones), so if/when we get something like #771 landed, we could go with (a) by listing the strings (like we currently do) and linking that table (so that the meaning of the strings was explicit).

If we decide to not change the existing (non-normative despite the “value is”?) line, I suggest we drop the enumeration from our JSON Schema.