5129: Allow Glean to be substituted for local development r=Dexterp37,travis79 a=badboy
Co-authored-by: Jan-Erik Rediger <janerik@fnordig.de>

5047: Fixes #5046: Updates guessFileName to use uniqueFIleName r=csadilek a=sblatz



5133: Closes #5077: Renames onDownloadCompleted r=NotWoods a=sblatz
Co-authored-by: Sawyer Blatz <sdblatz@gmail.com>

5130: Upgrade Glean to 21.2.0 r=mdboom a=mdboom
Co-authored-by: Michael Droettboom <mdboom@gmail.com>

5123: Deprecate StorageSync class r=rocketsroger a=eoger

It is not used by any of our products anymore (fenix, lockwise, fxr).
Co-authored-by: Edouard Oger <eoger@fastmail.com>

5120:  GeckoView update (beta) (20191121-140436) r=jonalmeida a=MickeyMoz
Co-authored-by: MickeyMoz <sebastian@mozilla.com>

5121: Closes #5090: Wire up GeckoView action delegate for BrowserActions r=psymoon,Amejia481 a=csadilek

This follows the same pattern as content/background messaging, with the only difference that we have to be able to register action handlers for each extension on every session. The latter is the reason I moved the session-specific action out of the `EngineObserver` into our web extension module. Ultimately, we want to get rid of`EngineObserver` anyway once we fully migrated to browser-state.

I am also going to add a browser action to our sample-browser extension, but I will do this as part of #4791, as this PR is already pretty big.

We will get new GV API for installing extensions i.e different calls for built-in and third-party extensions. For now I've also introduced a `supportActions` boolean, similar to our `allowContentMessaging` to be able to configure per extension if we need to hook up action delegates. We really don't need that for our current extensions, so it makes sense not to register all these handlers.
Co-authored-by: Christian Sadilek <christian.sadilek@gmail.com>

5119:  Public Suffix List update (20191121-140427) r=pocmo a=MickeyMoz
Co-authored-by: MickeyMoz <sebastian@mozilla.com>

5093: Add streaming for large messages r=jonalmeida a=espertus
Co-authored-by: Ellen Spertus <ellen.spertus@gmail.com>

5107: Use minus offset for vertical clipping. r=pocmo a=hiikezoe

After bug 1586144 the area which is initially covered by the dynamic toolbar
is outside of the ICB so that we need to use minus offsets.

https://bugzilla.mozilla.org/show_bug.cgi?id=1586144

Co-authored-by: Hiroyuki Ikezoe <hiroyuki.ikezoe@gmail.com>

5117: Closes #5109: Fix breaking change on GeckoView nightly 72.0.20191120094758 r=csadilek a=Amejia481
Co-authored-by: Arturo Mejia <arturomejiamarmol@gmail.com>

5110: Closes #5036: Add dialog for accepting addon permissions r=csadilek a=Amejia481

[Video demo ](https://drive.google.com/file/d/1xyLa539tuQD1hF078QMfV2dSNcSzq_8W/view?usp=sharing

)
Co-authored-by: Arturo Mejia <arturomejiamarmol@gmail.com>

5111: Upgrade Glean dependency to 21.1.1 r=mdboom a=mdboom
Co-authored-by: Michael Droettboom <mdboom@gmail.com>

5108:  Docs update (20191120-120645) [ci skip] r=pocmo a=MickeyMoz
Co-authored-by: MickeyMoz <sebastian@mozilla.com>

5083: Closes #5063: better exception reporting during migrations r=pocmo a=grigoryk

Patch 1:
>
    We are logging exceptions when no profile is found, which is actually a legit case.
    There will be no profile on a fresh install, for example.
    
    This patch makes these kinds of exceptions more precise/useful: we'll only send a report
    in case there's a profile but a missing dbPath. We'll now also send an exception in case
    of an IOException while parsing profiles.

Patch 2:
>
    Submit unexpected exceptions during migrations
Co-authored-by: Grisha Kruglov <gkruglov@mozilla.com>

After bug 1586144 the area which is initially covered by the dynamic toolbar
is outside of the ICB so that we need to use minus offsets.

https://bugzilla.mozilla.org/show_bug.cgi?id=1586144

5066: Add setDynamicToolbarMaxHeight API r=pocmo a=hiikezoe
Co-authored-by: Hiroyuki Ikezoe <hiroyuki.ikezoe@gmail.com>

5064: Closes #5041: Fix migration post-processing to understand FxA migrations r=pocmo a=grigoryk

When FxA migration was added, I forgot to adjust "read and parse past migrations" code
to account for a new migration type. This patch fixes that problem, and adds tests that
would have cought it.
Co-authored-by: Grisha Kruglov <gkruglov@mozilla.com>

5103: Closes #5050: Improve handling of authentication problems r=csadilek a=grigoryk

This PR ensures that account doesn't disappear on app restart after hitting authentication problems.

Also:
- there's some FxaDeviceConstellation cleanup/simplification
- profile cache is now used; this way, we don't need to fetch profile every time account manager is instantiated
Co-authored-by: Grisha Kruglov <gkruglov@mozilla.com>

If we don't do this, we end up calling onAuthenticated _after_ callin onAuthenticationProblems.

This isn't a very principled solution, since other similar situations aren't covered.
And, we may fail 'ensureCapabilities' for reasons other than authentication (e.g. network failures).

Arguably, stopping here _is_ better than progressing with an uncertain state.

Before this patch, we'd clear out account storage after we see an unrecoverable authentication error. In this context, a password change would be an unrecoverable error. We'll transition account into an AuthenticationProblem state, but upon re-initialization of the state machine we'll end up in NotAuthenticated instead, because there's no longer a locally persisted account state. So, this is just a straight-up bug in the state machine.

So, step 1:
    do not erase account storage if we encounter auth problems we can't auto-recover from
        this will make sure account isn't disappearing after a restart
        this has an additional benefit of not erasing fetched profile data, as well! it's part of the persisted account state

Also, add in some debug logging into the samples-sync app to make testing this a bit easier.

I'm not sure it was ever necessary, to be honest. I think the way the 'refresh'
method is currently structured, simply marking internal 'constellationState'
as Volatile is enough - we're not concerned about concurrent access to it,
only about memory visibility across threads.

It's true that currently, work in this class happens on a pool thread,
so it's possible to have two racing 'refresh' methods running. Having one of them
loose the race and drop results on the floor should be just fine in this case.

5094: Closes #5049: Add WebExtensionToolbarFeature r=psymoon a=psymoon
Co-authored-by: Simon Chae <chaesmn@gmail.com>

5092: Closes #5091: Fix clashing file providers in feature-prompts and feature-downloads. r=NotWoods,sblatz,csadilek a=Amejia481
Co-authored-by: Arturo Mejia <arturomejiamarmol@gmail.com>

feature-downloads.