frontend: optimize request transfer

[GabrielBuragev]

Previously, the code didn't account for the fact that it takes a certain amount of time from the moment
a user initiates a transfer request until he actually submits it via his wallet provider.
The transfer object was fetching & storing the target chain block at the moment of triggering a "createRequest" transaction call instead of after successful submission of the transaction call.

[fredo]

Can we be sure that we do not miss the fill event if we do this change?

Specifically I'm wondering whether we fetch the target chain block after the transaction was successfully submitted to the source chain. If that's the case I believe we have a race condition between fetching the start block and actually the request already being filled.

[compojoom]

I'm not sure if I would like to do this change now. Calling the contract function does a signer.sendTransaction(txRequest) and there are some old reports that sometimes metamask returns the hash immediately and sometimes it waits. (seems to be fixed in recent releases, but I would need more time to test)
ethers-io/ethers.js#372

Also, we always need to do getLogs for the old blocks. Whether we do 1 call that fetches only 20 blocks, or one call that fetches 500 - doesn't really matter I think.

[GabrielBuragev]

@fredo true, with this change we are actually opening the possibility for such cases, therefore, i am closing this.