The previous implementation did some ratelimiting, namely how many parallel
ActivateConnection D-Bus calls are in fly. This way we are able to kick off
many parallel calls, but the activations themselves were not ratelimited.

Rework the code. Now there are two rate limits (that can be set via environment
variables):

  NUM_PARALLEL_STARTING
  NUM_PARALLEL_IN_PROGRESS

This allows more control about how much is happening in parallel. If we are
going to activate 1000 profiles, then it matters that we do things in parallel,
but not everything at the same time.

lgtm.com complains about this. Avoid the warning.

It's an example for how to use libnm and asynchronous API.
But it's also a script I will use to test activating many
profiles in parallel.

Also add a test script that creates many veth interfaces and connection
profiles. So now you can do:

   sudo NUM_DEVS=100 contrib/scripts/test-create-many-device-setup.sh setup
   ./examples/python/gi/nm-up-many.py c-a{1..100}

and cleanup with

   nmcli connection down c-a{1..100}
   sudo contrib/scripts/test-create-many-device-setup.sh cleanup

Of course, be careful to do this on your production machine.

lgtm.com warns about unqualified "except". This catches any "BaseException",
when we really only should handle "Exception" here.

lgtm.com also complained about "connection_after" being unused. This
hopefully works around that warning.

They are flagged by lgtm.com. Avoid the warning by dropping unused
includes.

First of all, the "os.setuid()" call is never reached. lgtm.com warns about
that, and warnings are annoying because they require investigation.

This code is only in the example, so that the user would understand that
they should edit the source and set the desired UID. But you can only
call setuid() if you have CAP_SETUID, so commonly this anyway doesn't
work -- unless you are root already, and then you actually don't need
it either.

Let's drop this code from the example.

Maybe this example really should be dropped. Does the "dbus" python
module even still work? Doesn't for me...

input() in Python2 evaluated the string and was thus unsafe. On
Python2, the right choice is raw_input. In Python3, input does
what raw_input did.

Work around this.

The main "problem" is that lgtm.com flags this as error. The fix
in the example is not important, but getting a low number of warnings
is.