lnwire+peer: clamp pong bytes, make ping handler more effcieint

This was not properly enforced and would be a spec violation on the
peer's end. Also re-use a pong buffer to save on heap allocations if
there are a lot of peers. The pong buffer is only read from, so this
is concurrent safe.

lnwire/lnwire_test.go

@@ -864,6 +864,22 @@ func TestLightningWireProtocol(t *testing.T) {
 					NewShortChanIDFromInt(uint64(r.Int63())))
 			}
 
+			v[0] = reflect.ValueOf(req)
+		},
+		MsgPing: func(v []reflect.Value, r *rand.Rand) {
+			// We use a special message generator here to ensure we
+			// don't generate ping messages that are too large,
+			// which'll cause the test to fail.
+			//
+			// We'll allow the test to generate padding bytes up to
+			// the max message limit, factoring in the 2 bytes for
+			// the num pong bytes.
+			paddingBytes := make([]byte, r.Intn(MaxMsgBody-1))
+			req := Ping{
+				NumPongBytes: uint16(r.Intn(MaxPongBytes + 1)),
+				PaddingBytes: paddingBytes,
+			}
+
 			v[0] = reflect.ValueOf(req)
 		},
 	}