Originally reported here:

https://github.com/ovn-org/ovn-kubernetes/pull/4658#issuecomment-2314884878

With the test enabled in ovn https://github.com/dceara/ovn/commit/34c9fbbbc674f476f4635b97fd3982f68aaff7f7 the regression was bisected down to:

https://github.com/ovn-org/ovn/commit/4725ad125b42ce2938b864712187331f649776ad

controller: Avoid double controller action for ICMP errors.

The fields that are not directly supported by OvS were encoded
via additional controller action that changed the required value.
This was most notably needed for ICMP need frag messages.

Encode the field value loads as note action instead. This allows
us to find the note and act accordingly in the first controller
action witovnsb_db.dbhout the need to send it to pinctrl again, parse and
change the packet. This way we can also encode any future fields
that might be needed as this method should be flexible enough.

This change is completely transparent to the user and shouldn't
cause any disruptions.

The traffic pattern seems to be, with packets larger than configured MTU.

external_client -> provider ovs bridge -> localnet logical port -> GW router -> LB -> routing -> VIF.

NB and SB databases from a failing test run are attached.