fix(api): lock simultaneous tx insertsion with mutex

[perekopskiy]

What ❔

Fixes the lock for simultaneous tx insertion with mutex.

Why ❔

The previous approach could lead to a "stuck" state if the task panics/get canceled before hashmap entry is cleaned.
This shouldn't happen now with guard removing entry on drop.

Is this a breaking change?

• Yes
• No

Operational changes

No changes

Checklist

• PR title corresponds to the body of PR (we generate changelog entries from PRs).
• Tests for the changes have been added / updated.
• Documentation comments have been added / updated.
• Code has been formatted via zkstack dev fmt and zkstack dev lint.

[slowli]

I'm not entirely sure I understand how the code change correlates with the PR description 🙃 AFAIU, with the change, the lock for address_and_nonce now lasts longer (it's alive across DB manipulations), so the code doesn't just implement RAII semantics for a lock. If the only goal is to implement such semantics, I'd argue it'd be easier to wrap inflight_requests in an Arc and have a guard removing the entry on drop (probably by spawning a task since it has async logic):

struct Guard {
    inflight_requests: Weak<Mutex<HashMap<(Address, Nonce), H256>>>,
    address_and_nonce: (Address, Nonce),
}

impl Drop for Guard {
    fn drop(&mut self) {
        tokio::spawn(async move {
            if let Some(inflight_requests) = self.inflight_requests.upgrade() {
                inflight_requests.lock().await.remove(&self.address_and_nonce);
            }
        });
    }
}