multi: Add getaddrv2 and addrv2.

[sefbkn]

This depends on #2596 and the removal of the reject wire message.

This PR modifies the wire protocol by adding two new message types addrv2 and getaddrv2 and bumps the wire protocol version to 10. It also removes the need to perform DNS lookups in the address manager through HostToNetAddress by pushing these calls up the call stack and further decoupling the address manager from its caller. It does not introduce any new network address types and is intended to implement the minimum framework necessary to facilitate easily adding new address types in the future. The intention of this design is to allow supporting new address types through addrv2 through protocol version bumps moving forward. Changes that are not transmitted across the peer to peer network should not require version bumps and may be implemented without doing so.

These two new message types are intended to eventually replace their older counterparts, which are getaddr and addr respectively. A peer sending a getaddrv2 or addrv2 message with a protocol version less than 10 is in violation of the wire protocol and the peer is disconnected. Similarly, peers advertising a protocol version greater than or equal to 10 that send an addr or gettaddr message are in violation of the wire protocol and are disconnected.

A getaddrv2 message is similar in structure and purpose to a getaddr message in that it has no payload and functions as a request for a peer to reply with an addrv2 message if it has addresses to share. An addrv2 message is similar in structure and function to an addr message with a few key differences:

• Port is now encoded as a little endian value rather than big endian.
• Timestamp is encoded as a 64 bit value rather than a 32 bit value.
• A network address type field is now serialized with each address to indicate the length and type of the address it precedes.
• A message with zero addresses is no longer serializable.
• Addresses are serialized their most compact form, rather than always being encoded into a 16 byte structure.

[dajohi]

Does this handle torv3 addresses?

I also think the new addrmgr.NetAddress belongs in wire as NetAddressV2.

[sefbkn]

Does this handle torv3 addresses?

I also think the new addrmgr.NetAddress belongs in wire as NetAddressV2.

@dajohi No, torv3 addresses are not supported or broadcast in this PR, but the commit that introduces it and builds on these changes can be included if it seems appropriate for this PR.

Regarding putting this new type in the wire package, I need to follow back up on this one.

[sefbkn]

Converting this to a draft until https://github.com/decred/dcrd/pull/2596 is merged, since this pull request builds on that.

[davecgh]

#2596 has been merged.

[davecgh]

I was hoping to get this into v1.7, but it looks like I'm going to have to move this to 1.8 unless @sefbkn plans on finalizing it within the next few days.

[davecgh]

Alright, I'm through with the initial review. This also needs to be rebased to resolve the conflicts. Once everything is addressed, I'll give it another pass and thoroughly test it manually.

[davecgh]

Reminder on this one. Will need a rebase to resolve conflicts as well.