snat_v4_new_mapping creates a RevSNAT entry, then a SNAT entry for new
connections. However, we also have a fallback mechanism in
snat_v4_rev_nat_handle_mapping, which restores the SNAT entry if it was
evicted by LRU, but the original RevSNAT entry still exists.

There is a hypothesis that the above two functions may race with each
other, and the following is possible:

1. snat_v4_new_mapping creates a RevSNAT entry.
2. snat_v4_rev_nat_handle_mapping finds the RevSNAT entry and "restores"
   the SNAT entry (which has never existed yet).
3. snat_v4_new_mapping goes on to create the SNAT entry, corresponding
   to the RevSNAT entry, created previously.
4. snat_v4_new_mapping fails because the SNAT entry already exists,
   created by snat_v4_rev_nat_handle_mapping.
5. snat_v4_new_mapping then removes the RevSNAT entry, trying to revert
   everything.

The right outcome in this case would be to keep the SNAT entry, whoever
created it first, so it makes sense not to fail on -EEXIST.

It also makes the fallback mechanism more robust, because there is a
time gap between __snat_lookup and __snat_create.

Ref: #35304
Ref: #37747
Fixes: #38466
Signed-off-by: Maxim Mikityanskiy <maxim@isovalent.com>