As part of #151, this requires we introduce the ability to list
repositories based on `LIKE` SQL syntax, and then performing the
per-repo lookups.

Right now, we're not wrapping this up with Goroutines to improve
performance, and we'll optimise it in the future if needed.

We need to make sure we look up whether `totalAdvisories`,
`totalDependencies` or `totalPolicyViolations` are found in the query
and then generate the total values as needed, as we cannot wire in the
resolver (via GQLGen) to wait until the `repositories` field has
executed.

Co-authored-by: Keith Lyall <keith.lyall@deliveroo.co.uk>

This is the first GraphQL query from #151 that provides some more
significant querying of data, and so requires we wire in a new sqlc
querier.

This introduces queries that are largely taken from other places, to
retrieve the core data required by the query.

We can make sure to create lighter-weight queries for `Count`ing data,
as well as provide a helper method to convert DB types to GraphQL types.

To make sure that we can reference values that are having pointers
pointed to them, we need to make sure we handle loopvars correctly.

Co-authored-by: Keith Lyall <keith.lyall@deliveroo.co.uk>

As part of the implementation of a good first GraphQL API, we can use
the code from the `dependenton` report to produce the same data via
GraphQL.

As part of #151.

Similar to the underlying code that performs the reporting, we need to
add some complex conditionals to perform the right query.

To make sure that we can reference values that are having pointers
pointed to them, we need to make sure we handle loopvars correctly.

Co-authored-by: Keith Lyall <keith.lyall@deliveroo.co.uk>

As a design-first approach to considering how we will interact with
objects in the database using GraphQL as part of #151, we can introduce
the relevant types and enums.

Co-authored-by: Keith Lyall <keith.lyall@deliveroo.co.uk>

So we can get CLI documentation built into the docs site, as well as
embed the GraphQL schema into the docs.

This requires renaming the existing schema files/code to make it clearer
that they were for the database schema.

As part of #151.

Co-authored-by: Keith Lyall <keith.lyall@deliveroo.co.uk>

As a step towards #151, we can introduce the start of our GraphQL API.

We can start by adding support for DMD's inbuilt metadata table, which
right now has just the version of the CLI that was used to bootstrap the
database.

This introduces a separate CLI, `dmd-graph` that can be used to serve
the GraphQL API, as well as wiring it into the `dmd-web` CLI.

Co-authored-by: Keith Lyall <keith.lyall@deliveroo.co.uk>

Closes #320.

Bump Regal

See merge request !169

Add `dependenton` report

See merge request !167

As a step towards a required query for GraphQL implementation in #151 as
well as being a useful check anyway, we can introduce a common report
for listing the usage of a given package, and optionally at a specific
version.

This implements this as both a CLI and web-driven report. To make it
easier to use on the web, we can introduce a form to make it easier to
set the values.

There's a little bit of awkwardness with trying to query `version` and
`current_version` as part of the same query as not being present, where
we end up with an empty set of results. For now we can split this into a
separate query, and follow-up in #324.

This also proves a new model for performing `union`'d queries for
reports, rather than implementing an interface in each datasource.

Add policy to advisory summary output

See merge request !166

Allow `WARN` level for Policy Violations

Closes #277

See merge request !165

As part of #277.

As part of #277, we want to introduce the ability to `warn` in policies,
as well as `deny`.

This requires we introduce the new level, and make it possible to
retrieve the `warn` rule out of policies.

We can also refactor the key logic for evaluating policies' evaluation
results into a helper method, simplifying the work that needs to be done
and making it clearer in what cases something happens.

Closes #277.

As part of 1ecad150, these error
messages were missed.

As part of #277, we want to introduce the ability to `warn` in policies,
as well as `deny`.

This is a good prefactor, as it's a rather sizeable change, and requires
we:

- wire in the level to queries
- require that it's a single value, `ERROR`
- require that it is included in making a violation unique

In the case that `deny` is not specified, we'll receive:

    Error: failed to process any results for these policies. Check that
    you're returning the right variables

This isn't super helpful, especially when we can more cautiously look up
the value using `object.get`.

Remove workaround for regal's missing `fs.FS` support

See merge request !164

Now that upstream have released a fix for
https://github.com/StyraInc/regal/issues/492, we can pull this version
and simplify some of our code for packaging custom linting rules.

Introduce `external_licenses` for prioritised license lookups + consume licenses from SBOMs

Closes #223

See merge request !162

As part of #223, we want to consume licensing information from SBOMs, if
found. We've now introduced the `external_licenses` table, which will
house this data, we need to consume it.

We can update each SBOM parser and also pull out licensing information,
if present. With this data, we can then insert it in bulk into the
`external_licenses` table.

This requires we introduce a new `License` domain model, which matches
the schema for `external_licenses` and does _not_ match
`depsdev_licenses` due to us not storing a `package_manager`.

Although not many SBOMs - including those from Dependabot - include any
licensing information, we can at least wire it in, so as and when we
have the data made available, we can report on it.

Closes #223.

As we're going to need it for more than that, we can rewrite it as a
generic function.

In queries to report licensing data, we should prioritise the data
inserted into `external_licenses`, whether it's parsed by DMD, or has
provided by the user, as it is assumed that `external_licenses` is more
reliable.

We need to handle the cases where one or both tables have the data,
preferring `external_licenses`, as well as avoid returning any data when
both tables are absent.

This also amends how we retrieve data for policy evaluations, where we
need to make sure we add a per-dependency `group by`s as we're now doing
a `group_concat`, and otherwise we'll get invalid results. We want to
make sure the lack of licenses does not cause any issues with lookups,
as a dependency is still valid if no licensing data is made available.

As a step towards #223, we can introduce a new table,
`external_licenses`, which provides the ability to store licensing
information for dependencies, without relying on DMD's means for
determining license data.

As part of #223, this will be retrieved from SBOMs, but this also makes
it possible to sideload the data from other sources, such as more
consistent or reliable means (taking care to note #251!).

As we're adding a new table, we need to set up the boilerplate,
including the `repositories.Repository` interface.

Note that this is slightly different to `depsdev_licenses`, as this now
includes a `package_manager`.

As these values may be inserted manually, we should make sure that
validation is enforced on the table.

Fix: Correctly construct package names from CycloneDX SBOMs

See merge request !163

An oversight when collecting package names from CycloneDX SBOMs was
Maven coordinates appear in the format:

      "group": "com.fasterxml.jackson.core",
      "name": "jackson-annotations",

And as we only retrieved the `name`, we would be missing `groupId`s.

Prefix Datasette output in `dmd-web`

Closes #294

See merge request !161

To make it clearer that the output from Datasette isn't actually from
`dmd-web`, we can wrap it in the `prefixwriter` package's prefixed
`io.Writer`.

Closes #294.

De-duplicate `error` arrays

Closes #301

See merge request !160

As noted in #301, when i.e. providing an invalid policy, we return the
same error for each and every row in the database. This is unhelpful,
and should be avoided.

We unfortunately can't check for error equality with `==` or
`errors.Is`, so instead we can use a `map` that works based on the error
message value.

Closes #301.

Add an `unknown` license if deps.dev can't determine one

Closes #304

See merge request !159

As noted in #304, there are cases where a dependency is found in
deps.dev, but no license could be determined.

In these cases, the Web UI indicates that the license is "unknown", but
an empty array is returned by the API.

For these cases, we should make it clear to a consumer that the license
is `unknown`.

We can do this where the information is used, rather than in the client,
to make sure the client is a straightforward, docs-following,
implementation.

Closes #304.

Prioritise `current_version` for SBOM deps.dev lookups

See merge request !158

Otherwise we may get slightly worse data.

Provide licensing data to OPA policies

Closes #282

See merge request !157