Add python bindings for hwlib

[nadzyah]

This PR adds the ability to use hwlib functions in the Python code.
I've also documented how to install and use is in the client README

P.S. don't judge too strictly, this is my second Rust contribution :)

[Hook25]

A few inline suggestion, overall very clear README/code, thank you

[Hook25]

Possibly dumb question, could 2 be "System is certified for another ubuntu version" and 3 "System is certified for this ubuntu version"?

[nadzyah]

Good point! However, we don’t currently differentiate these states in the API server implementation. @mz2 should we add this state?

[mz2]

The "certified state exists for system" kind of response should cover both conditions of "system is certified for another ubuntu version" and "system is certified for this ubuntu version but your system differs from it". A better explanation for it would be "there exists a certified state for this system, you're presently not on it. Here's the delta: ..." (delta being supplied in form of the itemised, structured response including the state of the certified state(s) for a system like it)

[mz2]

If you're proposing including multiple "partially happy" scenarios as examples that could be toggled with this env state, that indeed does sound sensible in follow-up PRs once there exists some basic client.

[plars]

Overall, looks pretty good. One comment below. Also, I know it's just example data for now, but since we are adding python bindings, it would be good to go ahead and create a tests directory and at least add a simple python test to ensure it can be called from python. That gives us a good place to add additional tests to later.

[Hook25]

+1, merge it, keep in mind the possible followup with the status for exact match

[mz2]

Sorry I look to have left my review in draft. Fine for all this to be addressed in follow-up.

[plars]

This looks a lot better now, thanks for the tests! both the rust and the python tests work for me, as well as getting the expected results running things interactively.
+1

[p-gentili]

Awesome stuff, thank you very much for the Python tests and all the effort.

[mz2]

There's an unnecessary dance done in this implementation to first parse, then JSON stringify, then parse again (with a different, slower JSON parser, and parsing a different JSON than what came from the HTTP response since the stringify is done on Serde parsing output).

The runtime cost of this is not that problematic because the payload is predictably quite small, but there's a reliability concern: it's possible for one of the JSON parsing methods to fail, and for the Serde types to be different from the OpenAPI schema in some way. All of this we can wrangle in follow-up PRs, just noting this here for posterity.

[mz2]

Great stuff, thanks for adding tests, and I'm happy the async/await change was this simple to accomplish.

There is a follow-up needed at some later point in making the data available to the Python bindings: right now the data is parsed twice (serde's output is essentially thrown away whereas those structs could directly be exposed).