Prevent GeckoSession creation until tab is viewed

[bluemarvin]

Fixes #2227
To prevent memory exhaustion, this patch watches for memory trim system
callbacks and suspends inactive tabs by deleting the GeckoSession.
Additionally, when the application is started or resumed, inactive tabs will
not have a GeckoSession created until they are viewed. Any new background tab
will also not have a GeckoSession created until the tab is viewed.

[MortimerGoro]

After opening a few tabs and playing with switching I got a broken session. Video attached:

broken_session.mp4.zip
logcat.txt

[bluemarvin]

After opening a few tabs and playing with switching I got a broken session. Video attached:

broken_session.mp4.zip
logcat.txt

@MortimerGoro I think I've fixed the issue.

[keianhzo]

@bluemarvin I manage to get a reproducible crash:

STRs:

• Open FxR
• Switch to private mode and open 2 tabs
• Switch back to regular mode
• Start opening and switching between tabs until you start get suspended sessions in the log
• Switch back to private mode
• Open the tabs panel and switch to the inactive tab

The app crashes with the following stacktrace.

2019-11-13 16:58:51.089 14402-14402/org.mozilla.vrbrowser.dev E/GeckoCrashHandler: >>> REPORTING UNCAUGHT EXCEPTION FROM THREAD 1 ("main")
    java.lang.IllegalArgumentException: Display not attached
        at org.mozilla.geckoview.GeckoSession.releaseDisplay(GeckoSession.java:2409)
        at org.mozilla.vrbrowser.ui.widgets.WindowWidget.releaseDisplay(WindowWidget.java:1045)
        at org.mozilla.vrbrowser.ui.widgets.WindowWidget.onCurrentSessionChange(WindowWidget.java:1069)
        at org.mozilla.vrbrowser.ui.widgets.WindowWidget.setSession(WindowWidget.java:1029)
        at org.mozilla.vrbrowser.ui.widgets.Windows.addTab(Windows.java:1164)
        at org.mozilla.vrbrowser.ui.widgets.Windows.onTabAdd(Windows.java:1182)
        at org.mozilla.vrbrowser.ui.widgets.TabsWidget$TabAdapter$1.onAdd(TabsWidget.java:273)
        at org.mozilla.vrbrowser.ui.views.TabView$1.onClick(TabView.java:128)
        at android.view.View.performClick(View.java:5637)
        at android.view.View$PerformClick.run(View.java:22436)
        at android.os.Handler.handleCallback(Handler.java:751)
        at android.os.Handler.dispatchMessage(Handler.java:95)
        at android.os.Looper.loop(Looper.java:154)
        at android.app.ActivityThread.main(ActivityThread.java:6144)
        at java.lang.reflect.Method.invoke(Native Method)
        at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:886)
        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:776)

[MortimerGoro]

Another crash while testing: https://crash-stats.mozilla.com/report/index/55c55bd6-ddb6-4029-b9cb-f4a250191113

[bluemarvin]

I think both issues have been addressed but I'm sure there are more.

[keianhzo]

Couldn't trigger the crash anymore but I got this a transparent window after switching to a private session, same STRs as before:

I couldn't see anything weird in the logs:
logcat.txt

[bluemarvin]

The transparent window has to do with how we manage first paint. It's annoying but I don't think it is a blocker.

[bluemarvin]

Actually that transparent window is a problem. I thought it was only while the page was loading. I'll look into it quickly. But the fact that it is transparent means the compositor cleared it but then didn't render anything else.