Size msg forward message size better

The code in question is allocating a buffer to hold a header and a data payload then forwarding it on a socket.

The first thinko is that it sizes the buffer based on the data payload, which won't be enough for the header+data.  For the second thinko, when it realizes there isn't enough room, it adds the data size to the _capacity_ of the buffer, effectively allocating twice as much memory as needed.  (Aesthetically, I dislike adjusting the 'size' field of the structure to declare the buffer is larger before the buffer is actually made larger, thus the 'new_size' variable.)  This patch corrects those thinkos.

Motivation: As we all discovered with host parsing, xmalloc() of large data can be time-consuming, so avoiding it is preferred.  And in this case avoiding it for 2x the memory needed.  This is also a place where the xrealloc_nz() could be used, since the memory is immediately written into.  As you are probably aware, as peer counts creep into the thousands, this data payload creeps into the megabytes, so this can be a noticeable latency.

An alternate implementation is to guess the max size of the header, and allocate header+data and hope the realloc isn't needed.  I don't do that for a couple reasons.  If the guess is wrong, the worst case is that realloc will end up copying the buffer (full size, yet not without the data payload in it) to a new larger buffer, and I really dislike that prospect.  Better is to assemble the small header, and let realloc copy the small buffer into the huge new space.