[Feature]: Revisit fetch_unknown_ancestors in stacks api.rs

[cylewitruk]

Feature - Revisit fetch_unknown_ancestors in stacks api.rs

1. Description

The assumptions in this method are wrong, it uses the Stacks block height but the Nakamoto start height is defined as a bitcoin block height.

1.1 Context & Purpose

More context in issue #633 (comment) from #643.

2. Technical Details:

We should find a way to get the burnchain block height for the stacks block, or we could potentially keep looping until we get a 404 (not found) from the Stacks RPC endpoint, which is what it returns for /v3 endpoints when requesting data for non-nakamoto blocks.

2.1 Acceptance Criteria:

• Criterion 1
• Criterion 2
• Criterion 3

3. Related Issues and Pull Requests (optional):

• chore: move block observer testing stuff around #643

[djordon]

The assumptions in this method are wrong, it uses the Stacks block height but the Nakamoto start height is defined as a bitcoin block height.

Sorry, forgot to comment here and in the PR where we changed fetch_unknown_ancestors. I think what we should do is tie Stacks blocks with their anchored bitcoin block height and provide a final backstop that way. We set a bitcoin start height for which all signers need to have block headers for and use that to define a stopping point for fetch_unknown_ancestors when we are just starting out. So once we solve #559, we can revisit that function and use bitcoin blocks as a backstop.

[djordon]

I opened #685 which proposes us backfilling stacks blocks up until their bitcoin anchor block height equals some bitcoin start height. If we adopt the proposal in #685, then some of the work on the stacks side would likely relate to this issue.

[djordon]

I fixed this in #781. fetch_unknown_ancestors now fetches block ancestors until we get to nakamoto.