Provide access to original un-parsed api response

[tabaktoni]

At the current state for some endpoints, users are unable to get a real response, but rather parsed ones aligned with the provider interface. Also maintaining changes under existing assumptions are much more difficult than the pure implementation from Starknet updates.

1. _original naming solution
   One way to resolve this is to create local provider method outside of defined interface, that will have similar name but be distinguasged as the original respose.
   For example provider.getBlock() and provider.getBlock_original() will return un-parsed response.

2. channel solution
   Introduce a new class that will map request -> response based on the original API.
   Provider methods will use channel property to access endpoints and parse responses.
   The user will use the channel inside the provider if wants to retrieve the original data.
   provider.channel.get_block() , provider.channel.add_transaction(transaction) (transaction would have also pure form)
   This would allow easier updates as channels would be updated first with pure changes and then Providers will need to be updated based on now new state.

@ivpavici @dhruvkelawala @penovicp @janek26 @yoga-braavos

[penovicp]

The second proposal feels like the nicer approach to me.

The first proposal could be a plugin candidate once that system is set up. And as a tangent, then if both proposals get implemented with the first as a plugin it could serve as a template for moving away from the interface relationship between Account and Provider and enable the default Provider to be deprecated while allowing people to opt-in to the old behaviour via plugin.

[yoga-braavos]

Another suggestion:

Use openapi to auto generate the client and data model and save it alongside the current hand crafted api

a further idea around this:

have the hand crafted api fallback by default on the open api generated one will allow us to issue @next versions rapidly after starknet specs is updated