Motivation / Problem

During work on the STUN support, I kept running into the issue that NetworkAddress modifies its own object when it is resolved (which is done lazy). With the STUN support PR, we get "invite codes", which is another form besides ip:port to indicate the address of a server.

When analyzing this problem, I came to the realisation that we store NetworkAddress in many places, like NetworkGameList, while we simply mean to store the address where the server is. There is no need to have this uber complex object assigned to it for that, a simple string is sufficient. This also helps for "invite codes", as that is just another serialization of a servr address.

This means we now resolve connection strings to NetworkAddress a lot later now. The downside is that we do it slightly more often (every time you refresh/join a server instead of once when adding it).

Description

We now resolve the connection_string to a NetworkAddress in a much
later state. This means there are fewer places constructing a NetworkAddress.

The main benefit of this is in later PRs that introduce different types
of NetworkAddresses. Storing this in things like NetworkGameList is
rather complex, especially as NetworkAddress has to be mutable at all
times.

Additionally, the NetworkAddress is a complex object to store simple
information: how to connect to this server.

Limitations

Checklist for review

Some things are not automated, and forgotten often. This list is a reminder for the reviewers.

• The bug fix is important enough to be backported? (label: 'backport requested')
• This PR affects the save game format? (label 'savegame upgrade')
• This PR affects the GS/AI API? (label 'needs review: Script API')
  • ai_changelog.hpp, gs_changelog.hpp need updating.
  • The compatibility wrappers (compat_*.nut) need updating.
• This PR affects the NewGRF API? (label 'needs review: NewGRF')
  • newgrf_debug_data.h may need updating.
  • PR must be added to API tracker