Fix gas estimation for ETHSend transactions

[onyb]

There were two main issues with gas estimation for ETHSend:

1. We skipped querying eth_estimateGas for ETHSend transactions, and hardcoded the value 21000. This doesn't work for simple transfers to smart contracts which are slightly heavier in gas. We still fallback to 21000 if the call to eth_estimateGas fails in the RPC controller.
2. We were using 0x0 for the data field while querying eth_estimateGas, which always returned the following error response:

   {
     "jsonrpc": "2.0",
     "id": 1,
     "error": {
       "code": -32602,
       "message": "invalid argument 0: json: cannot unmarshal hex string of odd length into Go struct field TransactionArgs.data of type hexutil.Bytes"
     }
   }

   We never noticed this because we had a fallback to 21000 in place in case of an error. Turns out that geth wants us to either use "0x" or "" or completely omit the data field from the request for ETH transfers.

Resolves brave/brave-browser#19835.

Uplifts	1.34.x	1.33.x	1.32.x

Submitter Checklist:

• I confirm that no security/privacy review is needed, or that I have requested one
• There is a ticket for my issue
• Used Github auto-closing keywords in the PR description above
• Wrote a good PR/commit description
• Added appropriate labels (QA/Yes or QA/No; release-notes/include or release-notes/exclude; OS/...) to the associated issue
• Checked the PR locally: npm run test -- brave_browser_tests, npm run test -- brave_unit_tests, npm run lint, npm run gn_check, npm run tslint
• Ran git rebase master (if needed)

Reviewer Checklist:

• A security review is not needed, or a link to one is included in the PR description
• New files have MPL-2.0 license header
• Adequate test coverage exists to prevent regressions
• Major classes, functions and non-trivial code blocks are well-commented
• Changes in component dependencies are properly reflected in gn
• Code follows the style guide
• Test plan is specified in PR before merging

After-merge Checklist:

• The associated issue milestone is set to the smallest version that the
  changes has landed on
• All relevant documentation has been updated, for instance:
  • https://github.com/brave/brave-browser/wiki/Deviations-from-Chromium-(features-we-disable-or-remove)
  • https://github.com/brave/brave-browser/wiki/Proxy-redirected-URLs
  • https://github.com/brave/brave-browser/wiki/Fingerprinting-Protections
  • https://github.com/brave/brave-browser/wiki/Brave%E2%80%99s-Use-of-Referral-Codes
  • https://github.com/brave/brave-browser/wiki/Custom-Headers
  • https://github.com/brave/brave-browser/wiki/Web-Compatibility-Exceptions-in-Brave
  • https://github.com/brave/brave-browser/wiki/QA-Guide
  • https://github.com/brave/brave-browser/wiki/P3A

Demo and test plan

👉 Attn QA: The test plan consists of the following cases:

1. Create an ETH transfer. Verify that the gas limit is 21000.
2. Create an ETH transfer to the address 0x92cd4bd69e305634a72fc95992ecfa0699c784e7. Verify that the gas limit is 23276. The recipient address came from a user report (see Don't hardcode 21000 for gas limit for ETH transfers brave-browser#19835).
3. Create an ERC-20 token transfer. Verify that the gas limit is something large (typically more than 50000).
4. Create a swap transaction. Verify that the gas limit is something close to 200000.
5. Create a MATIC transfer on Polygon chain. Verify that the gas limit is 21000.
6. Create a token transfer (ex, PoS USDC) on Polygon chain. Verify that the gas limit is something greater than 21000.

Screen.Recording.2021-12-03.at.11.08.23.AM.mov

[yrliou]

Just a few nits left.