Privacy mode as default

[whymarrh]

Closes #6352, fixes #6320 and fixes #6110

This PR sets Privacy Mode to be "on"/enabled by default, leaving the toggle in settings to allow folks to disable it wholly and return the to old behaviour.

Components

• A notification is shown to users who previously had Privacy Mode disabled
• For users who are already using Privacy Mode, no notice is shown
• A "Share Address" notification is shown when the popup is opened on a tab that hasn't yet been connected (Allow manual enable for legacy sites. #6320, Add way to bypass privacy mode on a per-site basis #6110)

What does the migration notice look like

Users for who Privacy Mode was previous disabled will see:

What does the notification look like

The design: screenshot, and Figma

As implemented:

[danjm]

Only one minor requested change right now. I need to more carefully review the changes to app/scripts/ui.js and app/scripts/controllers/provider-approval.js. It seems to make sense, but I want to do another pass before final approval.

[danjm]

Everything below here is just moved from popup-core.js correct?

[Gudahtt]

In the separate notification bundle PR, I did essentially the opposite of this: I moved more things from ui.js into popup-core.js, because they were shared between ui.js and the newly created notification.js.

I'm guessing they were merged here because the separation wasn't useful? It will shortly become useful, so it might be worth moving everything back to popup-core.js. Or you can not bother, and I'll just do that when resolving this conflict in my PR - I don't mind.

Oh and you got rid of async too! 😅 That's funny, I did the same thing.

[whymarrh]

Everything below here is just moved from popup-core.js correct?

Yes, that file was only used here so I merged it/inlined it. The name wasn't quite accurate and it only had this single use.

I think this diff and your diff re-introducing separate files might be good together (that is, I'll leave this for now). It seems, er, semantically correct to me that we'd split things out later if needed.

[danjm]

Is this empty mapDispatchToProps necessary?

[whymarrh]

It is not, good catch!

[danjm]

So if I read this right, this notification is only meant to be shown once, correct? And that is after the migration?

[whymarrh]

Yes, once and only once

[danjm]

Okay, everything looks good to me. I've left a couple questions and we should make a decision on the comment from Mark. If this passes QA, I will approve.

[danjm]

@bdresser Tagging you as a reviewer as you probably have the sharpest sense of how this should behave, so I think a QA from you would be good.

Also, @tmashuang, if you could test that it behaves as expected in the case of a user who has privacy mode off before this update is made, that would be good.

[cjeria]

The notification component styles should be consistent with the notification references in this issue #6874

I'm noticing that there's an opaque bg-color applied to the button that is giving it a darker color than it's parent container.

Check out this pen to see how the styles are intended to be implemented https://codepen.io/cjeria/pen/mNmEYj

[whymarrh]

The notification component styles should be consistent with the notification references in this issue #6874

Yes, @danjm and I are aware that the two are slightly different and we'll need to merge both their implementation and design when both PRs are landed on develop.

I'm noticing that there's an opaque bg-color applied to the button that is giving it a darker color than it's parent container. Check out this pen to see [the styles]

Subtle catch, thanks. Fixed.

[danjm]

LGTM