plugin loader: Return immediately from search when cancelled

Set the search task's return-on-cancel flag to make it immediately
invoke the async callback when the cancellable gets cancelled.

This makes it possible to simplify the calling code.
shell search provider: Rewrite concurrent search handling logic

I failed to wrap my head around the current logic. This commit rewrites
the concurrency handling and simplifies it considerably, following
similar patterns as in the rest of gnome-software.

Not sure if this fixes the multitude of crashes reported against the
search provider, but it should definitely make it easier for me to debug
them in the future.
appstream plugin: Don't allow cancelling plugin startup

We were hitting a concurrency bug where quickly typing "software" into
shell overview search and hitting enter would bring up a non-working
gnome-software.

The cause turned out to be the shell search provider starting a search
on the "software" string, which in turn started appstream database
parsing in the appstream plugin. However, quickly hitting enter would
cancel the current search, and also cancel the database parsing midway,
leaving us without appstream data in the GUI.

Fix this by making the database parsing and appstream plugin startup
uncancellable.
Get rid of last two g_cancellable_reset uses

It's safer to create new cancellables each time instead of resetting the
existing ones.
Fix a race with displaying results from shell search provider

Clicking on an app in gnome-shell search results is supposed to bring up
the details page for that app, with the back button leading to the
search page, pre-populated with the same search that was done in
gnome-shell.

The code for this was all there, but it rarely worked properly because
we'd spawn two parallel async processes, one to switch to the search
page, and another one to switch to the details page. Whichever finished
last was the one that the user actually saw.

Fix this by properly chaining the async operations so that we'd always
end up on the details page.

https://bugzilla.gnome.org/show_bug.cgi?id=735798
Destroy the sources dialog when it's closed
sources dialog: Do teardown in dispose, instead of finalize

g_cancellable_cancel can lead to a callback from the async task. Doing
it in finalize is too late, since the template children teardown has
already happened at that point and we'd crash dereferencing NULL
pointers in get_sources_cb callback.

Fix this by moving the g_cancellable_cancel() call and the rest of our
teardown code to the dispose handler, so that it runs before the
template children destruction.
plugin loader: Set the return-on-cancel flag for all threaded tasks

This ensures that we get an immediate synchronous callback when we call
g_cancellable_cancel. Being able to rely on that makes the calling code
simpler and easier to understand.
Don't warn for cancelled operations

Check if the error matches with G_IO_ERROR_CANCELLED and avoid emitting
warnings in that case.
Disable text shadow for the updates counter label

White text with white shadow makes it look fuzzy. Fix this by adding
"text-shadow: none;" to the counter-label css class as suggested by
Sebastian Keller.

https://bugzilla.gnome.org/show_bug.cgi?id=737357
Make --details work again

Commit a69e779204348fc264185388d1a40f3bf602445e regressed this.
search: Simplify code for switching to the details view

No need to have the search page refine the app before passing it to the
details page; the details page handles it all for us.
app tile: Force icons to 64 px size

If the appstream data ships too large icons, it breaks category page
layout. Fix this by making sure the icons are shown in 64 px size.
Fix another race with displaying shell search provider results

Another race that caused us to come up with the search view displayed,
instead of the details view.

We were getting the delayed "search-changed" signal callback after
having already switched to the details view. If the computer was fast
enough and managed to launch the details view in 150 ms, then the
"search-changed" signal handler ran after that and caused us to switch
back to the search view.

Fix this by ignoring the next "search-changed" signal.
search: Don't ignore duplicate searches

Otherwise searching for the same string twice in gnome-shell leads to
the details page not coming up the second time.
trivial: Move a debug statement

Show app debug after having refined the app and we have all the details,
not before.
Always load the fallback icon at 64x64 size

This may be just a unmolested upstream icon or an SVG.

Should resolve: https://bugzilla.gnome.org/show_bug.cgi?id=738162