multiport: fix review findings in lane probing and recv_error

- Don't probe lanes on a tunnel idle in both directions, and don't count lane
  probes or their acks as tunnel traffic. A lane's own keepalive was keeping
  idle tunnels from ever being dropped by tunnels.drop_inactive.
- Accept a recv_error from an up lane's target. The peer answers lane traffic
  from the lane socket it arrived on, and the spoof guard only accepted the
  base remote, so recv_errors for lane traffic were ignored.
- Keep the probe generation across a lane reset, so an ack for a probe sent
  before a roam can't promote the lane on the new path.
- Bring handshake.proto in line with payload.go: field 3 is reserved and
  TxLanes is field 4.

handshake/handshake.proto

@@ -32,12 +32,14 @@ message NebulaHandshakeDetails {
   LaneDetails ResponderLanes = 10;
 }
 
-// LaneDetails advertises a host's multiport lane capability. On a base
-// handshake LaneIndex is 0 and PortCount/BasePort describe the sender's
-// consecutively bound UDP ports. On a lane handshake the initiator sets
-// LaneIndex to its (nonzero) lane number.
+// LaneDetails advertises a host's multiport lane capability. PortCount/BasePort
+// describe the sender's consecutively bound UDP ports, and TxLanes is how many
+// lanes the sender may send on, so the peer knows how many lane sessions it must
+// be prepared to receive on.
 message LaneDetails {
   uint32 PortCount = 1;
   uint32 BasePort = 2;
-  uint32 LaneIndex = 3;
+  // was a per-lane handshake index
+  reserved 3;
+  uint32 TxLanes = 4;
 }