Previously Android-Components - BrowserToolbarBehavior would be responsible
for positioning the snackbar above the toolbar.
With that responsibility removed we can handle in Fenix positioning the
snackbar depending on the toolbar and many more cases - like positioning it
depending on the download dialogs.
They were both in their packages by themselves, which feels unnecessary.
Unfortunately, a utils pkg is discouraged by kotlin but we don't have a
better place for them right now. Maybe an annotations/ pkg for the
latter?
* For https://github.com/mozilla-mobile/fenix/issues/5092 - Show a Snackbar with retry option if sharing to devices fails
ShareController will contain all the business logic for checking the result
status of the `share to device` operations. When this fails it will show a
snackbar which also offer the possibility to retry the just failed operation.
To allow this even in the event the user has closed the share fragment we'll
use a GlobalScope's coroutine.
Refactored out the TabsSharedCallback from ShareFragment because otherwise we
would have neede to sent through that the just failed operation. After the
refactor the ShareController is solely responsable for showing the right
snackbar and handling the retry actions.
* For https://github.com/mozilla-mobile/fenix/issues/5092 - Refactor ShareControllerTest
* For https://github.com/mozilla-mobile/fenix/issues/5092: Adds color theming of snackbars
This patch fixes a few issues:
- it was an extension on a CoroutineScope, but that was quite misleading
since the Main dispatcher would be always used regardless of what dispatcher
the owning CoroutineScope was configured with.
- timing was reliant on exact value of the undocumented Snackbar.LENGTH_LONG duration
- coroutine cancellation relied on cooperation of the 'operation' suspend function,
which we can't depend on
New 'allowUndo' fully controls its timing, doesn't imply a dispatcher to its consumers,
and doesn't rely on cooperation of passed-in suspend blocks for cancellation to work.