[Access] Add implementation BlockProvider

[UlyanaAndrukhiv]

Closes: #6584 , #6585

Context

In this PR implemented :

• DataProviderFactory which is responsible for creating data providers based on the requested topic.
• DataProvider which is the interface abstracts of the actual data provider used by the WebSocketCollector.
• BaseDataProvider and BaseDataProviderImpl - the interface and the concrete implementation which holds common objects for the provider.
• BlocksDataProvider which is responsible for providing blocks.
• BlockHeadersDataProvider which is responsible for providing block headers.
• BlockDigestsDataProvider which is responsible for providing block digests.

Added unit tests to cover this functionality.

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 61.43791% with 118 lines in your changes missing coverage. Please review.

Project coverage is 41.05%. Comparing base (85913ad) to head (f8668ef).

Files with missing lines	Patch %	Lines
...ckets/data_providers/mock/data_provider_factory.go	0.00%	28 Missing ⚠️
...st/websockets/data_providers/mock/data_provider.go	0.00%	24 Missing ⚠️
engine/access/subscription/util.go	0.00%	18 Missing ⚠️
engine/access/rest/websockets/controller.go	0.00%	13 Missing ⚠️
access/handler.go	0.00%	10 Missing ⚠️
engine/access/state_stream/backend/handler.go	18.18%	9 Missing ⚠️
.../rest/websockets/data_providers/blocks_provider.go	91.78%	4 Missing and 2 partials ⚠️
engine/access/rest/http/request/get_transaction.go	0.00%	2 Missing ⚠️
...ss/rest/websockets/data_providers/base_provider.go	86.66%	2 Missing ⚠️
...e/access/rest/websockets/data_providers/factory.go	88.88%	2 Missing ⚠️
... and 4 more

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #6636      +/-   ##
==========================================
- Coverage   41.05%   41.05%   -0.01%     
==========================================
  Files        2071     2076       +5     
  Lines      183431   183653     +222     
==========================================
+ Hits        75303    75393      +90     
- Misses     101823   101962     +139     
+ Partials     6305     6298       -7     

Flag	Coverage Δ
unittests	41.05% <61.43%> (-0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[illia-malachyn]

Please, wrap data_provider.Run() in a separate goroutine.

LGTM

[peterargue]

mostly smaller comments. I think you should expand on the data provider tests to include some happy path testing. I also think there's currently a gap that covers more end-to-end functional testing. That can come in a separate PR, but wondering if we will need more control than is possible using integration tests alone. what do you think?

[jribbink]

Are these response objects finalized?

Should this be a dedicated DTO similar to what exists when using REST (see here)? Casing and naming on REST endpoints is different than what these models will serialize to if directly marshalled into JSON.

Consistency aside, I'm also not sure that these models will serialize "properly" to JSON out-of-box. On the REST endpoints, large numbers are serialized to JSON strings instead of numbers which prevents integer overflow on JS clients. Without a custom JSON parser, JS clients have a maximum safe precision of 53 bits.

[Guitarheroua]

Hi Jordan! Yes, this is exactly what we missed. Thank you for pointing out this issue. As I see it, the solution could involve reusing the same converters and models as those for the REST API, or creating new converters similar to the ones we currently have for the REST API. We will discuss this and I come back to you with concrete answer.

[peterargue]

+1. the WS endpoint should return data in the same format as the REST endpoints.

[UlyanaAndrukhiv]

We have created a new issue to address this #6775

[peterargue]

looks good. we still need to address the response format issue, but that can be done in a follow up PR

[peterargue]

looks good. we still need to address the response format issue, but that can be done in a follow up PR