Support for microblocks streams

[lgalabru]

@zone117x are we already tracking the fact that this component will have to support microblocks streams? Should we go ahead and start working on this, vs waiting for the PR to merge?

[zone117x]

Let's use this issue to track the work stream.

High level work items:

• Process new microblock events
• Microblock db and fork/invalidation handling
• API endpoints / db read queries
• OpenAPI doc updates for new endpoints

[agraebe]

@zone117x do you think any of the above could be completed before the code freeze? something indicating if microblocks are used would be useful for the explorer. we could in that case figure out if we should show a hint that it might take ~10min before the tx is complete (which wouldn't be required for macroblocks usage).

@aulneau did I miss something? any other thoughts?

cc @diwakergupta

[dantrevino]

From a developer perspective, microblocks are essentially useless until their data and operations are exposed in a way that doesn't force me to do things completely outside of the SDK, and/or are supported across all of the necessary APIs ... to that end I'd like to request support for prioritizing this.

[zone117x]

It looks like the microblock event stream PR stacks-network/stacks-core#2571 should have everything the API needs at this point. Work on the API can begin against that branch.

[agraebe]

for the record, there are 2 more PRs related to this:

• fix: emit microblocks mined by the node itself, add microblock hashes stacks-network/stacks-core#2653
• feat: emit microblock header hash to event observer stacks-network/stacks-core#2654