Add support for multiple credit classes per project

[ryanchristo]

Summary

In the current implementation of the ecocredit module, each project is associated with one credit class. In the future, we may want to support multiple credit classes per project and the ability to add credit classes to existing projects.

Related to #882

---

For Admin Use

• [ ] Not duplicate issue
• [ ] Appropriate labels applied
• [ ] Appropriate contributors tagged
• [ ] Contributor assigned/self-assigned

[ryanchristo]

Expanding on the idea from https://github.com/regen-network/regen-ledger/issues/1032#issuecomment-1107800763. I think we should consider projects with multiple project ids, one for each credit class that the project has been accepted to and each project id would be used to create the batch denom for the given credit class. When a project is accepted by a credit class, a project id is generated specific to the credit class and added to the list of project ids. The id for each credit class would include the credit class id, i.e. C01-003, B01-001, etc.

[ryanchristo]

Moving the conversation in #1032 around support for multiple credit classes to the tracking issue.

@clevinson:

Long term goals for projects are:

• projects should be able to be created in a permissionless manner by organizations / individuals wishing to register their project on-chain with some set of off-chain metadata (e.g. a metadata_url pointing to an IRI & resolver)
• project can "apply" to credit classes, which indicates a project's desire to engage in a process of adhering to a credit classes' methodology and having credits issued at certain points in time of a project's lifecycle (e.g. at hte conclusion of a monitoring period)
• the creator of the on-chain project is the default "project admin". Project admins can can perform update actions on the project like update metadata, apply to credit classes, and set a new project admin

@aaronc:

I really think this should be solved with two database tables:

one for when a project is within a class, we could call this ClassProject one for a project which may relate to multiple classes, we could call this simply Project

ClassProject is basically what Project currently is. And my thinking is that its class-project-id should be - (ex. C01-001 or C01-FOO) and then batches would be ---. I think that's pretty much what we have now and I'm not sure I understand the issues with this.

ClassProject would contain a reference to Project which would contain generic metadata and jurisdiction information and an ID which is distinct from the current "class-level" project IDs we have now and which I'm mentioning above.

@technicallyty:

Not too convinced with the ClassProject name, so I searched around google to see if there was a better word for "a group of projects" and Program came up, which seemed like a pretty good descriptor for the purpose you've described above. Curious to hear thoughts on that name

@ryanchristo:

This aligns with my thinking. ClassProject sounds like a more flushed out version of what I was proposing for https://github.com/regen-network/regen-ledger/issues/883, where multiple project ids would exist that are class specific. I didn't think as far as how we would store information that is specific to the class-project relationship but that would be resolved with ClassProject.

I'm open to further discuss names but I think ClassProject makes sense given how we are currently naming join tables. The Project would be the project and the ClassProject would be the relationship between the project and a credit class, which also includes information specific to that relationship such as metadata for baseline measurements.