Do not call ssu to determine OS Version

[nephros]

See issue #33
https://github.com/sailfishos-patches/patchmanager/issues/33

Concept ported from @elros, ac0991b
https://github.com/elros34/patchmanager/commit/ac0991b1b27df010066fa4e3f8f287c6b1004a3e

[Olf0]

Even though you stated to "not speak Qt and C++", you seem to be able to write and express what you want very well. I can barely comprehend most of that, thus a big thank you for adapting elros34's code for PM2.

Code seems fine, but:

1. this bit, while valid I assume, seems unrelated to the overall change:
   elros34@ac0991b#diff-da6a1e0621bec30e25650901e8a69669572d302bbccc7f82e5fc81f4b90e4e68L312
2. Thinking of the upcoming sandboxing, how do we feel about reading files from /etc instead of dbus-calling a system service? There are rumors that the latter might break when sandboxing is turned on fully, and the former will break certainly if the app profile doesn't allow it. (There's a separate issue #64 on that though.)

• For point 1, I also believe it is unrelated.
• For point 2: Because there is not definite information, how these restrictions are applied, my stance is: "do not care about rumors"; lets test, when the code is out (or more specific information is provided, but that is purely theoretical with Jolla).

For a proper review, I kindly ask @b100dian to do this, because I can only provide uneducated statements (e.g., "The code is looking beautiful, like a dense forest of words; and with syntax hilightning it all becomes so colourful!" 😉).

[b100dian]

Changes look good, I just didn't test them.
In case there are problems with reading directly that file we can always add a dbus method on patchmanager-object to make the query for the UI plugin.

[Olf0]

Changes look good, I just didn't test them.

Mmmh, I always reviewed changes by reviewing them. 😜
More seriously, I never tested any changes up to now, before setting "Approved", just reviewed them thoroughly. I may test, if I am very curious / I deem a change very critical / I have time to spoil.

So I do / did not think that any kind of testing is required for approving a MR.
I also believe we should not set the quality-assurance and procedural hurdles too high, as that may stall processing MRs etc.

Do our opinions on this differ (@b100dian sounds a bit like they do)?
Are there some reviewing guidelines, policies or best practices I am not aware of (and which include some testing)?

In this specific case (and many others, when there are non-trivial changes to QML or C++ code), I cannot seriously review due to my lack of knowledge and experience. And I sure will not just hit "Approved" to let things proceed.

So @b100dian, it is either you or potentially nobody who approves this MR.

[b100dian]

This could have been breaking things, that's why the test - I don't test all PRs, of course. The visual ones if I'm more curious:)
Just did a quick run on this and it's fine.
I wasn't able to trigger the original bug just by running ssu re 4.2.0.20 (e.g. change to an non-existant version)

[nephros]

Damnit, too soon!

src/bin/patchmanager-daemon/patchmanagerobject.h/cpp must be updated to use the new osVersion actually, otherwise compatibility check on the web catalog does not work.
Sorry about that, fix incoming.