[DataAvailability] Implement fork-aware Execution Data Endpoints

[AndriiDiachuk]

closes: #7656

Context

• Refactored access and observer builders to initialize newly added members before creating snapshot mock.
• Updated backend endpoint (GetExecutionDataByBlockID).
• Added arguments to backend implementation to specify user query criteria.
• Updated test according to changes.

[peterargue]

added a few small comments. overall this looks good. will wait for the rest of your changes before doing a thorough review

[codecov-commenter]

Codecov Report

❌ Patch coverage is 12.80992% with 211 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
cmd/access/node_builder/access_node_builder.go	0.00%	83 Missing ⚠️
cmd/observer/node_builder/observer_builder.go	0.00%	51 Missing ⚠️
...ptimistic_sync/mock/block_execution_data_reader.go	0.00%	28 Missing ⚠️
engine/access/state_stream/mock/api.go	0.00%	19 Missing ⚠️
...cess/state_stream/backend/backend_executiondata.go	48.14%	13 Missing and 1 partial ⚠️
...executiondatasync/optimistic_sync/mock/snapshot.go	0.00%	13 Missing ⚠️
...utiondatasync/optimistic_sync/snapshot/snapshot.go	0.00%	2 Missing ⚠️
engine/access/state_stream/backend/handler.go	91.66%	1 Missing ⚠️

📢 Thoughts on this report? Let us know!

[AndriiDiachuk]

I didn’t add the notNil() check for any of the storages because some integration tests fail when it’s added. It’s expected that these storages can be nil at that point, they’re either initialized or being initialized later during module setup, depending on flags such as storeTxResultErrorMessages and executionDataSyncEnabled.

[peterargue]

If any of these storages are not set when this module is run, then the snapshot will store nil for the db. Then when the API requests the db, it will get nil and panic.

I think adding the notNil() check is a good idea. if anything is nil during bootstrapping, that points to an ordering problem that needs to be fixed.

[UlyanaAndrukhiv]

Adding a few small comments, but otherwise this looks good to me. I also agree with Peter's outstanding comments.

[peterargue]

mostly small comments. the main 2 were about error handling and bootstrapping. otherwise this looks good

[peterargue]

what happens if we remove all of the config for github.com/onflow/flow-go/module/executiondatasync/optimistic_sync and just let it generate all of the mocks? if it's only a couple extra we may not need, I vote we do that to keep the config simple

[AndriiDiachuk]

@peterargue yes, it will generate additional mocks for(PipelineStateConsumer, PipelineFactory, PipelineStateProvider, CoreFactory), which I believe is not too much. So I will remove the separate config for optimistic_sync.

[peterargue]

If any of these storages are not set when this module is run, then the snapshot will store nil for the db. Then when the API requests the db, it will get nil and panic.

I think adding the notNil() check is a good idea. if anything is nil during bootstrapping, that points to an ordering problem that needs to be fixed.

[UlyanaAndrukhiv]

Looks good to me! I left a few minor comments.