In particular for the first one randomization could trigger an additional
rekeying, which let the "Adding ESA ..." check fail. But even without
randomization (could be seen in the second scenario that already uses
`rand_time=0`) 4 seconds can apparently be too low some time.
After a rekeying the outbound SA and policy is deleted immediately, however,
the inbound SA is not removed until a few seconds later, so delayed packets
can still be processed.
This adds a flag to get_esa_id() that specifies the location of the
given SPI.
This test asserts that the handling of XFRM expire messages from the
kernel are handled correctly by the xfrm-proxy and the Esa Event Service
(EES) in charon-tkm.