Add metadata discovery endpoints for curves and exports

[louispt1]

Context

PyETM previously hard-coded the list of available curves and exports. Any new output required changes in pyetm too. These endpoints let pyetm discover available outputs at runtime so a new curve or export can be added to ETEngine without cascading changes.

Implemented changes

• Adds GET /api/v3/curves/metadata returning all registered hourly output curves with their name, type, and description
• Adds GET /api/v3/exports/metadata returning all registered annual exports with their name and description
• Introduces CurveMetadataRegistry, a registry populated at startup via an initialiser; curves and exports register themselves in their respective controllers

Related

Goes with this pyetm PR and this documentation PR

Checklist

• I have tested these changes
• I have updated documentation as needed
• I have tagged the relevant people for review

[noracato]

Smart thinking with the registry, as the exports are not available as models.

A few questions:

1. Why did you choose a new controller, and not implemented an index on both curves and exports?
2. I understand the want to register curves in the controller, as all info will be in one spot. But is that the correct spot for it? I would expect this more in some form of config.
3. We should come up with a common name for exports and curves: results? scenarioData? Like this the registry can carry the common name

Although I like the direction you are taking, this might need some more thought and design? A first step could be a hardcoded index endpoint, if you want this change to be merged soon.

[louispt1]

I tend to agree this maybe needs more thought? Like maybe the endpoints should all be discoverable in a consistent pattern, not just the curves/exports? What is the logical separation between these two (the shape is an obvious answer but maybe it requires more refinement).

What do you think about delaying this change until we have refined the API structure further? It's not too much trouble to manually update pyetm, and we will need fallbacks for stable versions anyway…