lib/osv: more schema alignment improvements, and other cleanups

[frasertweedale]

Note: 4 self-contained, sequential commits. Recommend to review each in sequence.

commit 4519a7605b20e57d3c0e0fab95d5862464c78fbb
Author: Fraser Tweedale <frase@frase.id.au>
Date:   Wed Jun 21 16:27:44 2023 +1000

    lib/osv: abstract over database/ecosystem-specific fields
    
    A general-purpose OSV library should not hardcode anything about the
    `database_specific` or `ecosystem_specific` fields.  Abstract over
    these.
    
    A naïve consumer can parse `Model Value Value Value Value` for no
    loss of information.
    
    A producer can instantiate unused database/ecosystem-specific fields
    at `Void`.  `()` is not recommended, because `Just ()` will
    serialise as an empty JSON array.

commit c6a6d09ef5cbb91b18fd68b90a27968f9fa056a4
Author: Fraser Tweedale <frase@frase.id.au>
Date:   Thu Jun 22 23:31:14 2023 +1000

    lib/osv: remove unused Affects data type
    
    We might use something like the `Affects` data type the HSEC
    `database_specific` or Hackage `ecosystem_specific` fields.  But
    this does not belong in the general-purpose OSV module.  So remove
    it.  (It might get reincarnated elsewhere, in a later commit).

commit a9e621842dfdc97e7591db719b199761bfb28e43
Author: Fraser Tweedale <frase@frase.id.au>
Date:   Thu Jun 22 23:33:36 2023 +1000

    lib/osv: make "purl" field optional, per spec

commit 0fa58fbe8d540016eb00a862ed8716857c954b0c
Author: Fraser Tweedale <frase@frase.id.au>
Date:   Thu Jun 22 23:37:58 2023 +1000

    lib/osv: add export list to Security.OSV

[blackheaven]

I think that abstracting is a bit early though, adding a bit too much complexity.

[frasertweedale]

The question is - do we want a general purpose library or something specific to our use case? From my POV it would be a shame to implement all the OSV machinery but hardcode the db/ecosystem-specific fields to our use case. I don't think it adds much complexity for users - at worst a few type annotations to declare the payload types.

[mihaimaruseac]

I'm also leaning in favor of a general purpose library if we're already working on it.

[frasertweedale]

Another approach would be Maybe Object for all those fields. Then users of Security.OSV have to manage the conversion themselves, and aeson parsing will not validate that the values match expectations. But I could live with that.

But I see it got merged. Thanks for the reviews :)

FWIW I do intend to extract Security.OSV to a separate osv package. I will do it later (less urgent than actually completing the OSV export, and other tasks). Maintaining a clean separation and keeping apart the types and behaviour specific to HSEC use case will make it an easy task, when the time comes.