[th/mptcp-flags-changes] mptcp: rework the way to enable MPTCP flags

1. The "enabled-on-global-iface" flag was odd. Instead, have only and "enabled" flag and skip (by default) endpoints on interface that have no default route. With the new flag "also-without-default-route", this can be overruled. So previous "enabled-on-global-default" now is the same as "enabled", and "enabled" from before behaves now like "enabled,also-without-default-route".

2. What was also odd, as that the fallback default value for the flags depends on "/proc/sys/net/mptcp/enabled". There was not one fixed fallback default, instead the used fallback value was either "enabled-on-global-iface,subflow" or "disabled". Usually that is not a problem (e.g. the default value for "ipv6.ip6-privacy" also depends on use_tempaddr sysctl). In this case it is a problem, because the mptcp-flags (for better or worse) encode different things at the same time. Consider that the mptcp-flags can also have their default configured in "NetworkManager.conf", a user who wants to switch the address flags could previously do:

[connection.mptcp]
connection.mptcp-flags=0x32   # enabled-on-global-iface,signal,subflow

but then the global toggle "/proc/sys/net/mptcp/enabled" was no longer honored. That means, MPTCP handling was always on, even if the sysctl was disabled. Now, "enabled" means that it's only enabled if the sysctl is enabled too. Now the user could write to "NetworkManager.conf"

[connection.mptcp]
connection.mptcp-flags=0x32   # enabled,signal,subflow

and MPTCP handling would still be disabled unless the sysctl is enabled.

There is now also a new flag "also-without-sysctl", so if you want to really enable MPTCP handling regardless of the sysctl, you can. The point of that might be, that we still can configure endpoints, even if kernel won't do anything with them. Then you could just flip the sysctl, and it would start working (as NetworkManager configured the endpoints already).