Send txs sequentially; add thread to check for unmined txs

[vitvly]

This PR does the following:

• do not send txs until previous one has been mined or discarded
• check for stale txs in check-tx-receipts thread
  • monitor tx execution via eth/track-tx! and eth/untrack-tx!

Some additional refactors have been made:

• add a multimethod for eth/execute dispatched on the value of offline-signing?
• replace update-[name]-hash with a generic update fn
• return tx-info maps from eth/execute fn. These are afterwards passed to eth/[un]track-tx! fns for DB/in-memory storage

After QA:

Small issues to fix:

• [x] too small timeout which triggers transaction to re-execute
• [x] two comments are persisted if 1 transaction was canceled because of timeout
• [ ] 'Deploying contract' - usually takes 1-2 min - is too optimistic

[vitvly]

Moved web3j-related code and tracker-related code to separate namespaces.

[vitvly]

QA notes:

As expired deployments/submissions/watches are re-executed now, it is necessary to check whether they actually do:)

Queries below will simulate a situation where a tx hash for deployment/execution haven't been mined in 15 minutes, therefore making it a candidate for re-execution.

1. In order to check whether expired deployments are re-executed:

   update issues set transaction_hash='<some_nonexisting_hash>', contract_address=null, updated=updated - interval '15 minutes' where issue_id=<issue_id>;

2. In order to check whether expired submissions (once PR has been merged) are re-executed:

   update issues set execute_hash='<some_nonexisting_hash>', confirm_hash=null, updated=updated - interval '15 minutes' where issue_id=<issue_id>;

[churik]

1. Too small timeout which triggers transaction to re-execute (Mainnet)

Steps: Requirements: GH account is whitelisted, signed app, test application is added to repo;

• create several issues (8 in my case)
• put bounty label an all issues

  Expected result:

  all transactions are mined successfully

  Actual result:

  3 of 8 transactions are canceled because of timeout (currently 5 min)

2. Two comments are persisted if 1 transaction was canceled because of timeout

Steps: Requirements: GH account is whitelisted, signed app, test application is added to repo;

• open any issue with canceled transaction (i.e. https://github.com/TestingEnvENV/TestEnvAtt5_1/issues/227)

  Expected result:

  1 comment (unsuccessful comment from bot will be replaced with successfull)

  Actual result:

  2 comments are persisted

3. 'Deploying contract' - usually takes 1-2 min - is too optimistic

I suggest to replace it with 3- to timeout time(IMO 10 min)

[churik]

Tested functionality

• Creating several issues with bounty label (6-10 items simultaniously; contract is deployed one-by-one);
• Full workflow for 1 bounty (created -> funded -> claimed -> PR merged -> funds transfer to BHunter)
• Re-deploy contract

Tested on Ropsten and Mainnet.

Comment 3. 'Deploying contract' - usually takes 1-2 min - is too optimistic depends on network speed and should be checked on prod and discussed separately, probably will move to the separate issue.

[churik]

@martinklepsch please merge if it is OK after review; QA is passed.