Most notably, it renames
  c_list_unlink_init() -> c_list_unlink()
  c_list_unlink() -> c_list_unlink_stale()

  $ sed -e 's/\<c_list_unlink\>/c_list_unlink_old/g' \
        -e 's/\<c_list_unlink_init\>/c_list_unlink/g' \
        -e 's/\<c_list_unlink_old\>/c_list_unlink_stale/g' \
        $(git grep -l c_list_unlink -- ':(exclude)shared/nm-utils/c-list.h') \
        -i

When activation of the connection fails with no-secrets, we block
autoconnect due to that. However, NMPolicy also unblocks such
autoconnect, whenever a new secret-agent registers. The reason
is obviously, that the new secret-agent might be able to provide
the previously missing secrets.

However, there is a race between
  - making the secret request, failing activation and blocking autoconnect
  - new secret-agent registers

If the secret-agent registers after making the request, but before we
block autoconnect, then autoconnect stays blocked.

  [1511468634.5759] device (wlp4s0): state change: config -> need-auth (reason 'none', sys-iface-state: 'managed')
  [1511468634.5772] device (wlp4s0): No agents were available for this request.
  [1511468638.4082] agent-manager: req[0x55ea7e58a5d0, :1.32/org.kde.plasma.networkmanagement/1000]: agent registered
  [1511468638.4082] policy: re-enabling autoconnect for all connections with failed secrets
  [1511468664.6280] device (wlp4s0): state change: need-auth -> failed (reason 'no-secrets', sys-iface-state: 'managed')
  [1511468664.6287] policy: connection 'tuxmobil' now blocked from autoconnect due to no secrets

Note the long timing between making the secret request and the
activation failure. This race already existed before, but now with
WPS push-button method enabled by default, the duraction of the
activation is much longer and the race is easy to hit.

https://bugzilla.gnome.org/show_bug.cgi?id=790571

Typedefs to structs are fine, but a typedef for a pointer seems confusing to
me. Let's avoid it.

Replace the usage of g_str_hash() with our own nm_str_hash().

GLib's g_str_hash() uses djb2 hashing function, just like we
do at the moment. The only difference is, that we use a diffrent
seed value.

Note, that we initialize the hash seed with random data (by calling
getrandom() or reading /dev/urandom). That is a change compared to
before.

This change of the hashing function and accessing the random pool
might be undesired for libnm/libnm-core. Hence, the change is not
done there as it possibly changes behavior for public API. Maybe
we should do that later though.

At this point, there isn't much of a change. This patch becomes
interesting, if we decide to use a different hashing algorithm.

https://bugzilla.gnome.org/show_bug.cgi?id=780199

[thaller@redhat.com: reworded commit message]