In addition to the Linux network stack, there's an additional "stack" intended to alter behavior but that is kept as much as possible separate from the network stack: Netfilter. This facility allows clients (still in kernel) to hook into it to intercept packets at various strategic places during its life in the network stack: that's used for firewalling and doing NAT. Among those clients but not only, there are iptables and nftables. Here's the corresponding Packet flow in Netfilter and General Networking schematic:
While this schematic was created with iptables in mind it's also applicable to nftables. In this answer, nftables has the same role as iptables. Most things said here about nftables is applicable to iptables (legacy or nft version) and vice-versa.
As can be seen an other important client (really considered to be part of Netfilter) is conntrack which keeps track of all flows seen, and is also doing the bulk of NAT handling using the same flow bookkeeping. NAT is not really handled by nftables: as written in the center of the schematic, it will receive only the first packet of each flow to be able to give an altering rule that will determine the fate of the whole flow (rather than the single packet): once the information is stored in the conntrack lookup entry, conntrack will handle it standalone, and chains of hook type nat will not see following packets from this flow.
So it doesn't matter: once a flow is already handled by conntrack it won't be affected by any change in nat rules, even if there are no more rules, simply because those rules are not used anymore.
What can be done to affect this flow is to query directly the conntrack facility. The relevant tool for this is called
conntrack (from https://conntrack-tools.netfilter.org/).
As OP wrote, it can be used to read information about conntrack entry, but can also be used to update, create, delete or flush (delete all) entries.
One can choose the granularity:
remove all entries:
remove all snat-ed entries (technically meaning that the reply destination address is not the same as the original source address in the lookup table):
conntrack -D --src-nat
all the way to a surgical removal of OP's entry specifying all elements even including the precise ICMP id (so this wouldn't disrupt an identical ping command also started before the NAT rules were removed, since the id would most certainly be different):
# conntrack -D -p icmp --orig-src 192.168.2.100 --orig-dst 188.8.131.52 --reply-src 184.108.40.206 --reply-dst 192.168.1.10 --icmp-type 8 --icmp-code 0 --icmp-id 13006
icmp 1 28 src=192.168.2.100 dst=220.127.116.11 type=8 code=0 id=13006 src=18.104.22.168 dst=192.168.1.10 type=0 code=0 id=13006 mark=0 use=1
conntrack v1.4.6 (conntrack-tools): 1 flow entries have been deleted.
(there's no reason Ubuntu 18.04LTS's
conntrack 1.4.4 behaves differently here)
Once this entry is removed, the next packet that was previously part of this flow will be seen as a new packet. Being in state NEW it will be given again a chance to be altered and will traverse the nat chains. As there will be no more any alteration, if it was egress it will traverse un-NATed to the next router which will probably drop it or pass it to a router which will drop it (because of Strict Reverse Path Forwarding or for specific routing rules for an RFC1918 address), if it was a late ingress reply from 22.214.171.124 it will be locally routed and ignored by the network stack: the ping command is disrupted and now times out.