Clear access boundaries throughout SDK

[esgraham]

Description

As a Carbon Aware application developer, I need to have clear access boundaries throughout the SDK, so that I am required to learn and implement the exposed classes.

SDK as a C# Client Library

Acceptance Criteria

• [ ] Ensure that only the public classes are available to the user within the SDK

Verify that the following WebAPI routes can be executed and return the expected results:

• [ ] GET emissions/bylocation
• [ ] GET emissions/bylocations
  • [ ] GET emissions/bylocations/best
• [ ] GET emissions/forecasts/current
  • [ ] POST emissions/forecasts/batch
• [ ] GET emissions/average-carbon-intensity
  • [ ] POST emissions/average-carbon-intensity/batch

Verify that the that following CLI routes can be executed and return the expected results:

• [ ] emissions
  • [ ] emissions-forecasts

• [ ] Unit Tests are completed and code passes tests

Dependencies

Task List

• [ ] List of tasks (punchlist) needed to complete the user story

Sprint-Ready Checklist

• [ ] Acceptance criteria defined
• [ ] Acceptance criteria is verifiable / testable
• [ ] External / 3rd Party dependencies identified
• [ ] Engineering team understands acceptance criteria
• [ ] Is the user story small enough to be implemented in a short amount of time, but large enough to provide value?

[gfmatthews]

At the moment, there's a wide range of places where we indicate that objects are public when in fact they should be internal or private or whatever is appropriate. This story is a cleanup task as noted in our SDK library design document as linked in the issue. Recommending this for approval

[juzuluag]

PR: Green-Software-Foundation/carbon-aware-sdk#256