WIP: exchange capacity parsing for the ENTSO-E parser

[VIKTORVAV99]

Description

Adds exchange capacity parsing for the ENTSO-E parser using the day-ahead capacity information (A61).

This still need some testing and such but it's open for comments.
Unfortunately, less zones than I was initially expecting had live capacity data for exchanges, but it does work well when it is available, and it will gracefully fall back if it's not.

One thing to note is that I needed to add 2 api calls to get this data so we might have to plan for that in the rate limits and wait for ELE-1595 until we merge this (1 api call if there is no data).

Also, just to note: This is technically forecasted capacity data but it should be orders of magnitudes more accurate than the static factors.

Preview

 {'capacity': [-2300.0, 3653.0],
  'datetime': datetime.datetime(2023, 3, 13, 18, 0, tzinfo=tzutc()),
  'netFlow': 2528.0,
  'sortedZoneKeys': 'ES->FR',
  'source': 'entsoe.eu'}

Double check

• I have tested my parser changes locally with poetry run test_parser "zone_key"
• I have run pnpx prettier --write . and poetry run format to format my changes.

[VIKTORVAV99]

FYI: @FelixDQ, @pierresegonne, @madsnedergaard

[madsnedergaard]

This looks very nice! We should definitely get the rate-limiting fixed, so we can implement this! :)

[VIKTORVAV99]

This looks very nice! We should definitely get the rate-limiting fixed, so we can implement this! :)

I think we should try and split it into its own parser function as well before we actually merge this. While the current implementation works and provides a good proof of concept it has some limitations:

1. There is no way to run it independently from the exchange parser.
2. It's only run for the exchanges using the ENTSO-E parser.
3. It's always run for the exchanges using the ENTOS-E parser regardless of data availability.
4. It does not return future values (would give even more value in regards to guiding estimations.)

(I also think it would make sense to run this just once per hour if implemented and not every 15ish min like the exchange parsers.)

[VIKTORVAV99]

@unitrium is this something we want to proceed with now that we have added the historical endpoint for ENTOS-E which free up some API calls?

Or should we add a new "capacity" endpoint to the parsers so capacity can be parsed individually from exchange data first?