The token is used to avoid people sniffing session-keys of other
servers. Without this, a bit of guessing can get you very lucky.
With this, you also have to guess a 1 in 256 value right. This is
unlikely.

The session-key now also uses the current time in the key. This
helps mitigate the above issue even further, as you now also have
to guess the time of the server correctly. Although this is more
likely for you to have right, it is at least better than having
a fixed value to use.

In the current OpenTTD implementation, all IPs send a register
packet to the master-server. When the client just started, this
is zero for all of them. This means the master-server cannot
detect this was from the same server.

By sending back a session-key to use, and waiting for the server
to use this, multiple IPs do end up with the same server.

For example, OpenTTD can send an unregister without register in
some odd cases. Or due to race-conditions in OpenTTD it can
register the server with two different session-keys on two
different IPs (IPv4 / IPv6 for example). This last case is very
unlikely to happen, but we protect against it anyway.

…ifferent things

We want to validate if people are guessing the token; for this you
first need to know if you know the session-key. After thatn you need
to validate if the token in the session-key is correct.

Don't auto-detect if a packet is a PROXY-protocol packet; that
can result in people faking their IP. Instead, only enable
PROXY-protocol if it is set as argument to do so, and after that
expect all packets to be PROXY-protocol packets. It is now up
to the system administrator to ensure no other network path exists
where a user can call the server without PROXY-protocol.

Additionally, we are going to drop "updater", and only query a
server every 15 minutes (instead of every 5 minutes) when ever
they re-advertise their server. This is sufficient for now, and
heavily reduces the complexity of the master server.

It caches the server-list for 30 seconds, as fetching all servers
from the database every time is pretty expensive in both costs
as latency.

There are two endpoints:
/server -> shows all the online servers including all their meta-data
/server/<server-id> -> shows information about the server, if it is still known
                       (can be online / offline).

<server-id> is the md5() of the IP + port of any of the IP/port
combos of a server. If the server has a dynamic IP, this will
constantly change. The server-id is only to lookup information
about a specific server with this API, and has no further purpose.

Information per server is only changing every 15 minutes, so caching
it for this long is fine.
For server-listing, 5 minutes can be a bit long, as it means that
new servers takes 5 minutes to show up in the API. But as the API
is for information-only, and not really used to connect to servers,
this is fine.

The benefit of caching it for 5 minutes, is that the DB is under
less load from the API, and people hammering the API won't have
any effect on the database. As it is easier / cheaper to scale
up the API, this is the best solution.