This enables UPnP mapping handling to cope with buggy IGDs/routers which
ignore requests for refreshing existing mappings, causing the mapping to
intermittently appear and disappear every 3 minutes approximately.  This
should help clients remain reachable to others for seeding content and
bridging connections (both with static and dynamic connectivity).

Enhancements:

  - Detect buggy UPnP IGDs and let mappings expire if only such IGDs are found
    in the network, then recreate the mappings ASAP.
  - Better computation of pauses in UPnP handling code to avoid extra delays.

Fix missing `std::chrono::ceil` in some C++1z implementations.

It does not seem to be available in some implementations of the C++1z draft
that do not implement the whole C++17.

Older compilers may attempt (and fail) to deduct `std::ceil` instead.

This enhances the handling of buggy UPnP IGDs (i.e. routers) which do not
allow refreshing still available mappings before their leases time out (see
[here][1]).  This showed up as the mapping being intermittently on and off for
periods of approximately 3 minutes.

[1]: https://github.com/miniupnp/miniupnp/issues/131

Now such buggy IGDs are identified and if they are the only IGDs responding,
then the client waits right until its (oldest) mapping times out, then adds an
equivalent mapping.

Clients now identify their mappings as `Ouinet-xxxx`, with `xxxx` being a
random hex value which changes on each run (it is shown in debug messages).

Other minor logging enhancements have been added too.

This may indicate some rogue UPnP server trying to trick or throttle us.

32-bit was probably overkill.

To be able to use the duration value.

Adding mappings to several IGDs and then checking whether they have already
added the mapping can delay the wait too much and make existing mappings
expire, so play safe by subtracting actual spent time from the wait.

Some older IGDs fail to refresh existing entries without an error.

To ease tracking our own mappings.

This enhances the handling of swarms in the client, especially to avoid a
long-running one to accumulate too many swarm entries, which results in the
client very seldom pinging injectors and thus stop announcing itself as a
bridge.

Enhancements:

  - Use a limited-size LRU cache to keep swarm entries at the client (to
    eventually drop spurious entries).
  - Do not ping injectors if a connection to one of them was successfully
    established while waiting for the next ping round.

This includes some enhancements to cope with transitory addresses appearing in
injector and bridge swarms, be they fake (attackers or BitTorrent spy nodes)
or genuine (like clients no longer available), as everything seen in the
swarms was never forgotten by the client, which caused the local view of the
swarm to grow indefinitely, causing issues like legitimate injectors never
getting picked for pinging in long-running clients.

  - Use an LRU cache for swarm entries in the client (to eventually drop
    spurious entries).
  - Also, do not ping injectors if a connection to one of them was
    successfully established while waiting for the next ping round.

Further refinement in swarm and ping handling paramenters may be needed, as
well as more sophisticated handling of the ping process.

Since we do not want iteration to allow altering the cache contents.  Also, it
is how it was being used until now.

Although we should probably do some serious statistics on them.

To help choose meaningful values.

Still need to figure out proper values.

To avoid entries from accumulating indefinitely, especially since they come
and go all the time.

Still failing to build as immutable is not yet properly supported by the LRU
cache.

Proper, different sizes need to be chosen for injector and bridge swarms.

The pause is not cancelled though, injectors are simply considered to be
reachable if the exchange happened during the pause.

This fixes some issues with the client announcing itself in the bridge swarm,
particularly in the pinging of injectors, which may eventually leave the
client out of the swarm and thus unreachable to others, especially after being
running for an extended period.

Enhancements:

  - Ignore DHT martians in the `bt-bep5` utility.  As a result, its output and
    that of `ping-swarm` are less cluttered and more useful.

Bugfixes:

  - Fix the computation of pauses between pinging injectors at the client, so
    that pings are not too far apart, which may cause the client's entry in
    the bridge swarm to become questionable.
  - Fix the selection of injectors to be pinged in each round, avoiding never
    actually pinging interesting injectors if they are located after a certain
    point in the internal list of nodes seen in the injector swarm.

If we choose a subset then shuffle it, we risk never pinging that appear after
the subset in the complete set of known injectors.  So first shuffle the whole
list and then choose a subset from the beginning.

This also avoids accidentally waiting more than expected when the time passed
since last ping is larger than the time remaining until the expected next ping.

This updates protocol specs to reflect Ouinet protocol v6, as well as
signalling with TODOs where the implementation needs work to completely
support it.

The description of the multi-peer download protocol is still missing, though.

This release improves logging of injector and bridge client announcements to
BitTorrent swarms, while fixing some issues which may result in both types of
nodes randomly disappearing from those swarms for a while.  It also makes
nodes more able to recover from local connectivity loss.

The release also fixes an issue affecting new Android builds (and breaking
CI/CD).

Enhancements:

  - Better logging of injector pings and BEP5 announcements.
  - Shorter interval of announcements to the injector swarm, to avoid the DHT
    entry to become "questionable" in BEP5 terms.

Bugfixes:

  - Avoid pausing after a successful announcement to the helper/bridge swarm,
    so that announcements follow injector pings.

Otherwise a build which starts with no Android SDK/NDK downloads may fail with
"NDK is missing a "platforms" directory.".

The export is done in `maybe_install_sdk()` (bootstrap mode) much in the same
vein as `ANDROID_HOME` is set in `setup_deps()`, although it may be better to
set them between bootstrap and build.