Rework IP fields in database

[kradalby]

This issue describes a long standing frustration, and is associated with a couple of other issues that will be breaking and used to be harder to solve. Since we break a bunch of stuff for 0.23.0, let us break some more.

Currently we store IPs in a very hacky list in the database from way back and issue #295 was created, one of the reasons is that we allowed for multiple prefixes to be defined (so multiple ipv4 or ipv6). These didnt really have an effect and we have now changed this to only allow one of each:

prefixes:
  v6: fd7a:115c:a1e0::/48
  v4: 100.64.0.0/10

Naturally, this means that machines will get one of each address, and this allows us to simplify the model for this in the database. Instead of having one list, we can have two colums: v4 and v6, containing the ip of the machine, and logic that automatically pulls it out as a netip.Addr. This will make the developer ergonomics a lot neater and simpler.

This simplification, with the help of the new IP allocator (#1756) should allow us to more easily fix a bunch of outstanding (and longstanding) issues:

• improve error message and document that the ipv6 prefix is now required #1785 (IPv6 support was accidentally made mandatory)
• Request: Guidance on Disabling IPv6 Address Functionality #1827 (Turn off IPv6, we should allow only one, either v4, v6 or both to be set)
• After adding IPv6 prefix in config, existing machines don't get IPv6 addresses #614 (If you regret that decision, addrs should be added if a new range is available)
• Feature Request: Random IP Address Assignment #968 (Bonus, allow random, not sequential IP assignment, should be easier with the new allocator)

The migration logic can be a bit hairy, what if some people, somehow has multiple addrs of the same family in the list in the database?