NAT encapsulated packets originate from `::`

https://github.com/oxidecomputer/dendrite/blob/f9fba02fd5351f468b15bda21d83d6dedae90818/dpd/p4/sidecar.p4#L507-L530

I ran into this while writing up tests for ICMP generation in OPTE and double-checking what fields to expect in various cases -- the case in question being generating ICMP hairpins for traffic from the external network.

The lack of a useful source address makes it challenging/fiddly to ensure that inner ICMP packet-too-big traffic goes back via the switch the original packet came from. The switch will only decapsulate packets which have one of its switch addresses as the outer IPv6 destination, so mirroring the source/destination addresses on the encap will lead to unroutable packets. As a result we have to perform a V2B lookup on the inner destination to fill this field, which may return the address of the other switch.

A minor point is that the inner source mac could also be set to something like oxide_vpc::engine::overlay::TUNNEL_ENDPOINT_MAC (A8:40:25:77:77:77), for symmetry with how OPTE sends packets to boundary services.

Start with dpd/p4/sidecar.p4 lines 507-530 and trace how NAT-encapsulated packets get their outer IPv6 source and destination addresses. Review the OPTE ICMP-generation tests mentioned in the issue to establish expected hairpin behavior. Done means the generated encapsulation has a useful source address and the relevant cases are covered by tests.