Add Flatpak assets and update metainfo

[oskirby]

Description

Now that the 2.24.1 release is out for Linux, I want to submit the application to flathub. However, the landing page doesn't look very good right now without some screenshots and graphical assets. This attempts add them to the project and cherry-picks some of the updates from the submission I am working on.

The URLs to these screenshot and logo assets need to be hosted at an HTTPS-accessible URL, so it's not sufficient to add them to the flathub repository. We need to host them somewhere, so why not in the project repository?

Some thought for future goodness: the screenshots can be localized. Some automation to generate the screenshots for each available locale, and upload them all as a bundle to the GH pages would be pretty neat.

Reference

i.e Jira or Github issue URL

Checklist

• My code follows the style guidelines for this project
• I have not added any packages that contain high risk or unknown licenses (GPL, LGPL, MPL, etc. consult with DevOps if in question)
• I have performed a self review of my own code
• I have commented my code PARTICULARLY in hard to understand areas
• I have added thorough tests where needed

[mcleinman]

Just one question.

[mcleinman]

What do the changes in this file have to do w/ the Flatpak assets for flathub?

[oskirby]

The NetworkManager changes are not required for updating the org.mozilla.vpn.metainfo.xml manifest - I can pull them out and address this later.

Where the change came from: In my travels, I had noticed that Surfshark was able to build the libnm library without needing to build udev so I used their flatpak as a learning excercise in how to remove some unnecessary cruft from our build and minimize the dependencies.

[mcleinman]

I think changing our sources should be a different PR, as that seems like a potentially risky change that should be thought about separately.

[mcleinman]

I think this should be two PRs. What do you think?

[mcleinman]

I think changing our sources should be a different PR, as that seems like a potentially risky change that should be thought about separately.

[oskirby]

I think this should be two PRs. What do you think?

I agree.

[oskirby]

I have removed the libnm changes, and added a few more screenshots and then loaded them into the metainfo XML document. Unfortunately, this causes the appstream linter to fail for now because the URLs won't be publicly accessible until this PR is merged, which makes this a bit of a chicken-and-egg kind of situation.

[mcleinman]

Thanks!