Early receives: allow nodes to process most incoming direct packets ASAP

[redxdev]

Right now a node can only process a direct packet if it is receiving the final hop (i.e. the entire path has been consumed), but this seems like it is unnecessary for payload types that are easy to check destination hashes on.

For example, consider a packet with path A,B,C with a destination of D. If node D can hear A directly, there's no reason for it to wait for C to repeat the packet before replying.

There was already an exception for ACKs that worked this way, so this change extends that to a few other payload types that all have easy access to the destination hash.

[redxdev]

Just noting that this is a slight behavior change, and opens up one weird edge case: if a packet has the local node as part of the path and as the destination (i.e. the full path is something like A,B,C with a destination of B) then the packet won't be received early as retransmit logic takes priority here. I could restructure the code to avoid this situation, but it's a bit nonsensical in the first place and I'm not sure it's worth fixing.

[redxdev]

Also noting a potential downside of this change: this will result in a node processing more packets in total, since it will now process any direct packet with a destination that has the same 1-byte hash as itself. Previously this would be somewhat protected against since it would only process a packet with a colliding destination hash if it could hear the final hop in the path.

That said, I don't think this is a big deal - flood messages end up having to be processed the same way already where a node can't tell if it is intended as the destination until it attempts to decrypt the payload, so this seems like it should be fine.