Add ent schemas and project config files

[jhoward-lm]

Initial ent schema definitions.

[jhoward-lm]

@puerco

Added a mixin schema so that all the other schemas get 4 additional fields:

SourceType

Either cdx or spdx to keep track of the original SBOM format

SourceData

Contains the original JSON data of the CDX or SPDX type

CDXExtra

Any CycloneDX fields from the source document that protobom is unable to express, for use in reconstructing the document later

SPDXExtra

Any SPDX fields from the source document that protobom is unable to express, for use in reconstructing the document later

Might be able to be combine CDXExtra and SPDXExtra into just ExtraData or something like that

[puerco]

Thanks for the PR @jhoward-lm ! Can we scope this PR to just the ent backend? Essentially to just go.mod/dum and everything under backends/ent.

Some of the other parts of the repo it is touching will eventually be handled org-wide so we probably don't need them here. If any of them are important (such as CI :) feel free to open other prs and we can merge them separately.

[puerco]

Thanks @jhoward-lm ! Looks good overall just two comments:

1. I'm not sure about the native format mixins. At the point where we'll interface with the storage backends, none of the data from the native formats will be available to store.
   
   I feel this needs a little more discussion. As this is likely to change I would rather strip it out for now and merge it after we establish a way to wire it in and what the data could look like.

2. Second, some minor repo housekeeping comments.

Thanks for working on this!

[puerco]

At some point we should start enforcing the boilerplates across the org, probably using the same tools we use in other projects. We usually hold the boilerplates in the hack/boilerplates dir, such as this one: https://github.com/openvex/vexctl/tree/main/hack/boilerplate

Let's not block on this, but if the generator can import these lines from the boilerplates dir it would be great as we would only need to maintain one file.

[jhoward-lm]

See my other question about the file name and license text content of the file header. I had trouble getting an accurate file name for the individual files being generated, but what about the license text?

Isn't hack/ typically used for things like dev scripts? This template is specifically scoped for and tied to ent code generation, and referenced as a relative path in entc.go. I guess if we feel confident this backends/ent/template path will never change, maybe entc.go could be changed to something like

// from
gen.MustParse(gen.NewTemplate("header").ParseFiles("template/header.tmpl"))

// to
gen.MustParse(gen.NewTemplate("header").ParseFiles("../../hack/boilerplate/header.tmpl"))

My thought was having it as a relative subdirectory seemed cleaner to me, and aligns with the ent codebase structure

[puerco]

We can wire this in later, it's just that in the future having a single boilerplate template if possible will be better.

Isn't hack/ typically used for things like dev scripts?

We are carrying a lot of automation from the kubernetes world that relies on the ./hack dir, some of that includes the boilerplate checks. We could have it elsewhere but if we can just reuse some of that why not :)

[puerco]

I am in general not very fond of checking in a lot of IDE config but I don't mind if you'd like to have it. But if we want to keep it it should go at the root.

[jhoward-lm]

Originally, I had the file name and license text in the file headers, which the snippet was auto populating, based on the guidance from here stating file name is required and here outlining how to add the Apache-2.0 license to source files (example). Should we consider adding them back in?

To me, the snippet file is there not so much as IDE config as it is for developer convenience, the goal being to reduce copy-paste errors and human error in general. Before removing the file name generation, if using VSCode (which I believe most devs are these days), you could just start typing "spdx", "license", or "header" at the top of the file to auto-populate with the current year and name of the file. If it stays, it needs to remain in .vscode/ according to their docs.

That being said, just to explain my thought process and not to advocate for anything, I typically include VSCode configs (.vscode/) and .editorconfig in my projects as a means to level-set and automate the consistency of code quality from contributors. It helps with code reviews when there is a level of confidence that the code is automatically formatted during development so the focus can be on the real content of the changes. I can also see the counter-argument of being too prescriptive.

[puerco]

We chatted and we're dropping the filename from the header (the requirement in the link above is for SBOMs). Since we'll have fixed boilerplates we don't need the editor automation .

[puerco]

This is awesome @jhoward-lm , thanks for your hard work on this!
/lgtm