Research and develop potential solution for hardening custom endowments

[david0xd]

Related to: #1017

This is supposed to be a smaller ticket that will reflect part of work needed for above mentioned ticket for hardening custom endowments.

It is required that we find a proper way and approach for hardening ethereum and snap endowments.

• Identify security risks for these endowments
• Identify how these endowments should be hardened
• Try to find a way for testing these endowments
• Try out some potential implementations if possible

[david0xd]

After research it is determined that hardening custom endowments should follow an approach implemented for hardening common (JavaScript) endowments (#1058).
Nothing else was discovered that would require doing hardening of these endowments in a different way.

During the research, one problem and security risk was identified that would cause issues with StreamProvider. The issue was that harden would freeze the prototype chain of the stream properties that are needed to be changed later in the runtime of it. This issue can be resolved by additionally securing proxy in a specific way that will be implemented within this work.

PR that is outcome of the research and will be continued until final development is done: #1172

Given that the StreamProvider internals should not be exposed at all, it is proposed to refactor it by using private hash methods and properties: MetaMask/providers#244
Note: This is not a requirement (blocker) for the hardening work, since the issue is resolved by fixing it on a proxy level.

The implementation work for the hardening of custom endowments will be followed here: #1017

[david0xd]

This research is now considered as done and development will continue in another task: https://app.zenhub.com/workspaces/snaps-615b3a7c08d2b20015eb6c4e/issues/gh/metamask/snaps-monorepo/1017