Adjust to AppStream 1.0 API changes

[ximion]

Hi!

This patch adjusts Flatpak to build with the currently in-development AppStream 1.0 series as well as the older 0.16.x series.
While AppStream 1.0 is not currently released yet, I also do not expect any major API changes to happen anymore (if everything goes well we will release it late this or early next month), so this patch should be safe to merge already, for future-proofing.

Cheers,
Matthias

[ximion]

@TingPing I think I slightly misread your original request and made a few more changes than was actually requested, but I kept them in the patch since I think they actually make sense:

• I dropped the as_* namespace prefix from the helper routines - that was a bit of an odd thing, since it made Flatpak provide functions under the appstream library namespace, which would clash if such functions were ever introduced by the appstream library. Furthermore, they weren't even consistent, e.g. component_get_flatpak_id existed before, while as_app_get_version did as well. So I just called it component_* everywhere (but we could also prefix it with flatpak_ or something else if that's better.
• cpt -> component where it was less-used
• If we haven't checked if our component is actually an app, it's now called component/cpt consistently, instead of mixing the two terms.
• Since AsStore isn't actually used but AsMetadata is, call the functions after that instead of the older appstream-glib API names

All in all, it's still a fairly self-contained change though.
One thing I do wonder though: At no point does the code check whether the component is actually an app - it could be a font, an icon-theme, an addon or a runtime at any point. Should it check that somewhere? (Since the ID matches, I also could not think of any issue that would arise from not checking this though, except maybe if the UI calls an addon/runtime an app as well... - so it is probably fine as-is).

[ximion]

Thank you! :-)

[TingPing]

One thing I do wonder though: At no point does the code check whether the component is actually an app - it could be a font, an icon-theme, an addon or a runtime at any point. Should it check that somewhere? (Since the ID matches, I also could not think of any issue that would arise from not checking this though, except maybe if the UI calls an addon/runtime an app as well... - so it is probably fine as-is).

For the search/remote-info/remote-ls commands I don't think its a major issue.

But maybe when flatpak build-update-repo/flatpak build-export is used it should actually validate the component type to not confuse software stores.

[ximion]

Once AS 1.0 is out and that feature is wanted, I'd probably look at the code again, there's some things which could potentially be simplified and some parsing could be avoided :-)
If we validate aggressively and the component-types don't match though, I wonder what the action would be in that case... Maybe only print a warning, so people fix their data? (or have annoyed users file a bug to have people fix their data, which so far didn't seem to have the greatest of successes, unfortunately).

[TingPing]

I doubt it is a common problem but I also think its of low importance, a warning is probably fine.