[IMPROVEMENT] Url redirection

[gantunesr]

Description

Write a short description of the changes included in this pull request, also include relevant motivation and context. Have in mind the following questions,
1. What is the reason for the change?
2. What is the improvement/solution?

The description of this PR can be found in,

• https://github.com/MetaMask/mobile-planning/issues/312
• https://github.com/MetaMask/mobile-planning/issues/311

Screenshots/Recordings

If applicable, add screenshots and/or recordings to visualize the before and after of your change

Use case: General QR code reading
https://user-images.githubusercontent.com/17601467/178322039-92f6b571-97e2-4c9a-b6cb-29e48250515d.MP4

Use Case: Reading address
https://user-images.githubusercontent.com/17601467/178322082-50d46c76-23e9-4e4f-9953-9560f59a2741.MP4

Issue

Detailed in the section above.

Checklist

• There is a related GitHub issue
• Tests are included if applicable
• Any added code is fully documented

[owencraston]

I tested the change and everything seems to be working as expected. NICE ✅. I just left a few comments on the code.

[owencraston]

🚢 The code looks great. Thanks for implementing those suggestions I made. In my opinion this code is really clear and robust 💪

[cortisiko]

@gantunesr Testing is done. I left a comment with my test cases here. I am going to swing this back your way. Also, just a heads up in the below bug report when I say "in-app camera" I mean tapping on the camera icon in the top nav on the wallet view.

Issue 1:
This issue has two parts:

A).
When I use the in-app camera to scan an address QR code I am prompted with the modal letting me know that I am about to visit an external link

furthermore, IF I am on a custom network and I were to scan a mainnet address QR code, I am taken to the send flow with a brief error message ” Recipient address is invalid” before the address resolves itself. View at the 28-second mark
B)
When I use the send flow QR code to scan a receive QR code I am prompted with the unrecognized QR modal

to reproduce:
have a production build of the app on device B
while on the wallet view tap on the receive button to open your address QR code
on device A, scan the QR code on device B

If I were to scan an address QR code in production I am able to proceed to the send flow without any issues. If I were to scan the keystone receive QR code I am able to proceed to the send flow with no issues

Issue 2
If I were to scan an invalid QR code using the in-app camera I am NOT prompted with the invalid QR modal

But if I were to scan an invalid QR code by using the camera in the send flow, I am prompted with the correct error message

To reproduce:
Using the in app camera scan: https://www.screencast.com/t/nGFsbbVE

Issue 3
Potential design issue: The Url redirect modal differs from that of the designs. See here

[gantunesr]

@cortisiko

• Issue 1-A: Fixed in the last commit (c13b578)
• Issue 1-B: Fixed in the last commit (c13b578)
• Issue 2: I think we need to consult @holantonela to know what should is the proper behaviour here. From what I understood, the warning modal only shows up in screens that the input should be an address.
• Issue 3: The component is not developed yet. It will be included in the next iteration.

[holantonela]

UPDATE

Discussed with Guto offline. We will leave this as it is right now and I opened this ticket for handling during the next iteration #4984

--

Issue 2: I think we need to consult @holantonela to know what should is the proper behaviour here. From what I understood, the warning modal only shows up in screens that the input should be an address.

Good point. We limit the scanning surface data in each camera view BUT i agree that if the QR code is invalid as malformed or unreadable, we should warn users consistently.

Is it doable @gantunesr?

[cortisiko]

@gantunesr This PR is QA passed 🌮 🌮 🌮

Test cases for this PR are covered here & here. I also confirmed that scanning keystone QR codes (keystone account receive QR code && transaction QR codes) are not broken