This reverts commit e13de2bf511d40d6e5c4e356ee5f550a1e53b57b.

Certain ip-tunnel modules automatically create network interfaces (for
example, "ip_gre" module creates "gre0" and others).

Btw, that's not the same as `modprobe bonding max_bonds=1`, where
loading the module merely automatically creates a "bond0" interface. In
case of ip tunnel modules, these generated interfaces seem essential to
how the tunnel works, for example they cannot be deleted. I don't
understand the purpose of those interfaces, but they seem not just
regular tunnel interfaces (unlike, "bond0" which is a regular bond
interface, albeit automatically created).

Btw, if at the time when loading the module, an interface with such name
already exists, it will bump the name (for example, adding a "gre1"
interfaces, and so on). That adds to the ugliness of the whole thing,
but for our unit tests, that is no problem. Our unit tests run in a
separate netns, and we don't create conflicting interfaces. That is, an
interface named "gre0" is always the special tunnel interface and we
can/do rely on that.

Note that when the kernel module gets loaded, it adds those interfaces
to all netns. Thus, even if "test-route-linux" does not do anything with
ip tunnels, such an interface can always appear in a netns, simply by
running "test-link-linux" (or any other tool that creates a tunnel) in
parallel or even in another container.

Theoretically, we could just ensure that we load all the conflicting
ip-tunnel modules (with nmtstp_ensure_module()). There there are two
problems. First, there might be other tunnel modules that interfere but
are not covered by nmtstp_ensure_module(). Second, when kernel creates
those interfaces, it does not send correct RTM_NEWLINK notifications (a
bug), so our platform cache will not be correct, and
nmtstp_assert_platform() will fail.

The only solution is to detect and ignore those interfaces.  Also,
ignore all interfaces of link-type "unknown". Those might be from other
modules that we don't know about and that exhibit the same problem.

Ubuntu 18.04 comes with iproute2-4.15.0-2ubuntu1.3. The
"/etc/iproute2/rt_protos" file from that version does not yet support
the "bgp" entry. Also the "babel" entry is only from 2014. Just choose
other entries. The point is that NetworkManager would ignore those, and
that applies to "zebra" and "bird" alike.

This helper function already loads the module and performs
additional checks. Use it.

This will make sure that the IP tunnel module is loaded. It does so by
creating (and deleting) a tunnel interface.

That is important, because those modules will create additional interfaces
that show up in `ip link` (like "gre0"), and those interfaces can interfere
with the tests.

Also add nmtstp_link_is_iptunnel_special() to detect whether an
interface is one of those special interfaces.

"debug" is implied when setting NMTST_DEBUG, but not specifying
"no-debug". This change has thus no effect, but it seems clearer to be
explicit.

The "debug" flag affects nmtst_is_debug(). Note that tests *must* not
result in different code paths based on debug, they may only

 1) print more debug logging
 2) do more assertion checks.

Having more assertion checks can result in different outcome of the
test, that is, that the additional assertion fails first. That is
acceptable, because failing earlier is possibly closer to the issue and
helps debugging. Also, when the additional failure is fixed and passes,
we still will fail at the assertion we are trying to debug.

Seems this test fails easily under gitlab-ci, if we set NMTST_SEED_RAND
to something else than "0". There is nothing particular special about
"0", except that there randomly different code paths are chosen.

A randomized test that doesn't pass on all systems with all random paths
is broken. Disable for now. Needs to be fixed.

Replace TRUE or FALSE for their NMUnmanFlagOp enum member. It is more
intuitive for newcomers so they can understand what is being set without
looking at the values or function logic.

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1516