Give datagram receiver access to current connection path

[Mark-Simulacrum]

This allows the receiver to differentiate the handling based on the connection's remote address. For example, if a datagram receiver wants to process the payload differently depending on the source address, this allows it to do so. The path a connection takes may change over time, so passing this state on each on_datagram call seems like the best bet.

One alternative design (not thoroughly explored) is to expose the datagram payloads to the Subscriber interface, and just have the datagram provider ignore payloads. Since there are no payloads anywhere in that trait today that I can see, it seems like it might be intentional to not surface them there?

This doesn't fully address #1565, but does surface most of the (by me) currently desired information. Based on poking around the code it seems like there would be more extensive changes required for the Connect struct to gain fields that are generic, I'm not sure it's worth making that investment now.

Call-outs:

The usage of the event API Path struct here is a bit odd -- I'm not sure if there's a better type to be using. Maybe we should be defining a datagram-specific wrapper.

Note also that this will be a breaking change to the datagram trait -- if we wanted to avoid that we can define a new method on the trait with a default implementation that calls the current one, but seems like it might make sense to just make the change while the interface is still unstable.

Testing:

No particular testing yet.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[Mark-Simulacrum]

I'll wait to fix tests/clippy until we decide on whether this is the right general direction or if we want to pursue one of the alternatives.

[Mark-Simulacrum]

Alright, revised implementation to be future-extensible to pass more information in and tests are now also passing.