With nIdCount being incremented for each addr received, an attacker could cause an overflow in the past, see https://bitcoincore.org/en/2024/07/31/disclose-addrman-int-overflow/
Even though that attack was made infeasible indirectly by addr rate-limiting (PR #22387), to be on the safe side and prevent any regressions change the nIds used internally to int64_t.
This is being done by first introducing a user-defined type for nIds in the first commit, and then updating it to int64_t (thanks sipa for help with this!).

Note that nId is only used internally, it is not part of the serialization, so peers.dat should not be affected by this.

I assume that the only reason this was not done in the past is to not draw attention to this previously undisclosed issue.

ninja all check-all