…in above collections. (mozilla-mobile#20633)

The kotlin-allopen plugin could be getting applied for each variant we
have in the app. With the changed code, it will only get applied once.

This was moved to once per day in https://bugzilla.mozilla.org/show_bug.cgi?id=1628413 when Google Play reviews were very slow. That hasn't been a problem for awhile, and the less frequent nightlies are causing delays getting new Android Components bumps shipped out.

* Filter out test target packages in Flank-x86
* Ignore verifyRunBlockingAndStrictModeSuppresionCount

…bile#20839)

Co-authored-by: Ryan VanderMeulen <ryanvm@gmail.com>

…ttingsFragmentReducerTest

…tsSuggestionProviderTest

…lures in HomeFragmentTest

The expectation is that replacing `return` with `answers` will compute
the return value for the extension function again in order to avoid the
error, "no answer found for: Settings".

…ProtectionExceptionsInteractorTest

…arViewTest

This test seems to be hacking at the binding between Fenix and the
BrowserToolbar to simulate toolbar events passing to the Fenix
interactor.

This is rather clumsy test that relies on the magic working of mockk
instead of following a general unit testing strategy that would commonly
require the class to be re-written to allow for better testing instead.

It is far safer to remove this test since we are not guaranteeing
anything in it and instead we see intermittent failures that make us
lose more time.

So therefore.. 🔥

…bile#20859)

…mentStoreTest

…king protection panel

…ck settings

…on navigators

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

…to ETP details

…Settings from the Tracking Protection dialog

… test

Fixes for TrackingProtectionExceptionsInteractorTest to remove the lamba
mocking and test actual BrowserState changes instead (where possible).

…bile#20891)

…actory.

For details on the root cause, see the commit. We replaced the similar
proguard rules because:
- the key line was returning false instead of true
- the other line had the same outcome as the written code. I believe it
  was a micro-optimization. Since perf seems fine without it, let's
  remove it

I benchmarked this change on COLD MAIN first frame. We see an
improvement of 89ms:
- before: 1346ms
- after: 1257ms

…ures

… we do not have a set lastAccess

The bug here was that we'd try to record `now - 0` as a viewTime delta.
This isn't just an obviously wrong value to record, but it will also
overflow our storage - we'll end up with a value on disk that doesn't
fit into an i32, but HistoryMetadata.total_view_time is i32 in our Rust
struct. Once that happens, reads that touch this bad row will result in
an overflow and a crash.

…uick settings.

This allows recording part of history metadata to ride the trains.
The UI features are still guarded by the secret settings flag (or,
enabled on debug builds).

…o View Binding.

…iew Binding.

…ctorTest

Not ready for prime-time. Lot of work still to be done.

This ensures that we do not attempt places initialization before
Megazord.init() finishes, and that touching BrowserStore does not
kick-off places initialization (due to the `cleanup` call being a
side-effect of creating metadata middleware, used as part of the
BrowserStore).

Glean initialization happens before initialize megazord, and it touches
core.store BrowserStore instance, kicking-off places initialization on
an IO thread (due to the cleanup call), which raced megazord
initialization on the main thread.

App init sequence is a bit of a mine-field, so this patch takes the easy
way out and doesn't attempt to re-order initialization sequence. Also,
initializing places as a side-effect of touching BrowserStore was also,
clearly, a bug.

…ction UI tests

 ...from tabsTray, inactiveTabs section.

This means no code will be generated by Kotlin Android Extensions for caching
views and also for @parcelize annotated classes.

As recommended in the official documentation
https://developer.android.com/topic/libraries/view-binding/migration#gradle
we need to switch on using `kotlinx.parcelize.Parcelize` instead of
`import kotlinx.android.parcel.Parcelize`

For mozilla-mobile#17917 - Remove the `kotlin-android-extensions` plugin

This means no code will be generated by Kotlin Android Extensions for caching
views and also for @parcelize annotated classes.

As recommended in the official documentation
https://developer.android.com/topic/libraries/view-binding/migration#gradle
we need to switch on using `kotlinx.parcelize.Parcelize` instead of
`import kotlinx.android.parcel.Parcelize`

Since all usages of Kotlin synthetics are removed and no such code is generated
anymore there is no need to keep around this Detector anymore.

Two new events are added:
- "inactive_tabs_expanded" for when the inactive tabs section is expanded
- "inactive_tabs_collapsed" for when the inactive tabs section is collapsed

For tracking when an inactive tab is opened / closed I've repurposed the
existing tabs tray telemetry (since the functionality uses the same code)
- tabs_tray.opened_existing_tab
- tabs_tray.closed_existing_tab
to support an extra "source" key indicating the feature from which a tab was
opened or closed. The current values for this new key are:
- "Tabs tray" for when a tab was opened/closed from tabs tray
- "Inactive tabs" for when a tab was openes/closed from the Inactive tabs
section of the tabs tray.

…n home screen (mozilla-mobile#20316)

* Add telemetry probes for recent bookmarks on home screen. Tests for controller.

* Make the events into counters in the metrics ping

Update tests to reflect new metrics

Add data review link for new metrics

Mock new settings for startup metrics tests

Update metrics

Add test for recent bookmark glean events

* Recent bookmarks controller tests

…iments

…lla-mobile#20982)

Flank https://github.com/Flank/flank/releases/tag/v21.08.1 has the fix for avoiding crash one of their API calls that we hit a couple times.

…bile#21010)

Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>

…yView into HistoryInteractor