Feature/reporting state

[mikejturner]

• Adds serializable equivalents of envoy models (SiteReadingType as ReadingType, Site, SiteDER, SiteDERRating, SiteDERSetting, SiteDERAvailability, SiteDERStatus).
• Stores all the data required to create a Cactus Test Procedure in the ReportingData dataclass and writes the data to a .json file in the zip archive, that is returned to the orchestrator during finalization.

[joshvote]

Is it a fair summary that this loads up the finalize zip with a new "json dump" file and then orchestrator can go do what it wants with it?

It wasn't how I initially imagined it (I was initially imagining a new endpoint to collect data on demand) but that's not a judgement call. It might actually be a lighter weight way of managing things...

[mikejturner]

Yes that is a fair summary.

The problem is not so much around having a dedicated end-point but about when the reporting data is collected...

• If before test finalisation, then it's possible further client interaction might happen, making the reporting data stale.
• If after test finalisation, then there's no active test which makes generation of reporting data very difficult.

Which is why I landed on returning the reporting data during finalise. However finalise already must return a zip of other files that cannot be generated by the orchestrator. The workaround was to return the reporting data inside the zip. JSON seemed the logical choice because it could easily be converted back into the python objects that the report generation code needs. A small bonus is we can return the PDF (generated by the runner) and the reporting data and then later compare the original (runner) PDF with the orchestrator-generated PDF to see that they match.