12a49ca Limit the number of new addressses to accumulate (Pieter Wuille)

`fGetAddr` is an old flag that indicates an ongoing GETADDR/ADDR interaction.
Introduced in dd51920, it prevents further
relay of received ADDR answers to other peers via the `RelayAddress()` gossip
mechanism while set - probably to prevent ADDR traffic from being dominated by
large GETADDR answers. 

It also used to be possible to receive a large GETADDR answer spread over
multiple ADDR messages (each bounded to max 1000 addresses), so the condition
`if (vAddr.size() < 1000) pfrom.fGetAddr = false;` was meant to ensure that
`fGetAddr` would only get cleared once the last ADDR of the package was
received (typically with < 1000 addresses).

However, `fGetAddr` is no longer useful for two reasons:
- 5cbf753 introduced the condition
`vAddr.size() <= 10`, so messages with more than 10 elements won't be relayed
further regardless.
- since bitcoin#5419, we do not get more than one ADDR message in response to GETADDR
because `vAddrToSend` cannot have more than 1000 elements.

Removing the flag will change behaviour in two special cases:
1.) If the GETADDR response is exactly of size 1000, `fGetAddr` will not not
be cleared on current master, so that the next "regular" ADDR message by this
peer won't be relayed - this does not seem intentional, changing it arguably
fixes a bug.
2.) If the response to GETADDR is small  (<=10 addresses), it will be relayed
to peers just as any other ADDR message of that size.

`fGetAddr` is an old flag that indicates an ongoing GETADDR/ADDR interaction.
Introduced in dd51920, it prevents further
relay of received ADDR answers to other peers via the `RelayAddress()` gossip
mechanism while set - probably to prevent ADDR traffic from being dominated by
large GETADDR answers. 

It also used to be possible to receive a large GETADDR answer spread over
multiple ADDR messages (each bounded to max 1000 addresses), so the condition
`if (vAddr.size() < 1000) pfrom.fGetAddr = false;` was meant to ensure that
`fGetAddr` would only get cleared once the last ADDR of the package was
received (typically with < 1000 addresses).

However, `fGetAddr` currently does not work as originally intended and is no
longer useful:
- typically, the first ADDR we receive from a peer after sending the GETADDR
is not the GETADDR response but the self-announcement of our peer. If this is
the case, `fGetAddr` acts on it (preventing its relay) and is already
inactivated once the GETADDR response is received.
- 5cbf753 introduced the condition
`vAddr.size() <= 10`, so messages with more than 10 elements won't be relayed
further regardless.
- since bitcoin#5419, we do not get more than one ADDR message in response to GETADDR
because `vAddrToSend` cannot have more than 1000 elements.

Removing the flag will cause initial self-announcements from outbound peers to
be gossip-relayed.