Added /v3/tenures/blocks/{consensus_hash} endpoint

[rdeioris]

Description

This patch adds the first (of 3) new endpoints allowing getting the list of stacks blocks given a burnblock (here by consensus hash, next endpoints will cover height and block hash).

It is part (along the simulation block api #6346) of the features required by wormhole.

[Jiloc]

You are missing the update to the openapi spec

[rdeioris]

Note: i rollbacked the BurnHeaderHash usage as it serializes to an array of numbers by default.

[jcnelson]

LGTM; just a couple nits and then I'll approve

[Jiloc]

Sorry for chiming in late after you’ve already done the work 🙏.
Not saying we should change this right now, but I was wondering if a recursive query could be more performant than doing ~120 queries per endpoint call.

I haven’t even tested it and is missing some of the fields (and only for nakamoto), but here’s a quick sketch of what it might look like:

WITH RECURSIVE tenure_chain AS (
    SELECT
        h.index_block_hash,
        h.parent_block_id,
        h.consensus_hash,
    FROM nakamoto_block_headers h
    WHERE h.index_block_hash = ?1
      AND h.consensus_hash = ?2

    UNION ALL

    SELECT
        h.index_block_hash,
        h.index_block_hash,
        h.consensus_hash,
    FROM nakamoto_block_headers h
    JOIN tenure_chain tc ON h.index_block_hash = tc.parent_block_id
    WHERE h.consensus_hash = ?2
)
SELECT *
FROM tenure_chain
ORDER BY block_height DESC;

[rdeioris]

The goal was to "split" the I/O (both db and socket) in multiple operations. With this approach we are doing all in a single "blocking" operation. @jcnelson any thought? Eventually changing that part is not a big deal.

[Jiloc]

I am fine with both approaches, the reasoning behind the split makes sense as well.

[Jiloc]

waiting for the tests to wrap up before approving, but LGTM!