Make use of the new size hint functions in btcwire.

This commit changes a couple of sections which deal with large lists of
inventory vectors to use the new size hint functions recently added to
btcwire.  This allows a bit more efficiency since the size of the list is
known up front and we can therefore avoid dynamically growing the backing
array several times.  This also helps avoid a Go bug that leaks memory on
appends and GC churn.

blockmanager.go

@@ -1092,7 +1092,7 @@ func (b *blockManager) handleHeadersMsg(bmsg *headersMsg) {
 // fetchHeaderBlocks is creates and sends a request to the syncPeer for
 // the next list of blocks to downloaded.
 func (b *blockManager) fetchHeaderBlocks() {
-	gdmsg := btcwire.NewMsgGetData()
+	gdmsg := btcwire.NewMsgGetDataSizeHint(btcwire.MaxInvPerMsg)
 	numRequested := 0
 	startBlock := b.startBlock
 	for {

peer.go

@@ -490,9 +490,11 @@ func (p *peer) PushGetHeadersMsg(locator btcchain.BlockLocator) error {
 func (p *peer) handleMemPoolMsg(msg *btcwire.MsgMemPool) {
 	// Generate inventory message with the available transactions in the
 	// transaction memory pool.  Limit it to the max allowed inventory
-	// per message.
-	invMsg := btcwire.NewMsgInv()
+	// per message.  The the NewMsgInvSizeHint function automatically limits
+	// the passed hint to the maximum allowed, so it's safe to pass it
+	// without double checking it here.
 	hashes := p.server.txMemPool.TxShas()
+	invMsg := btcwire.NewMsgInvSizeHint(uint(len(hashes)))
 	for i, hash := range hashes {
 		// Another thread might have removed the transaction from the
 		// pool since the initial query.