Add last_sortition_ch to RPCTenure

[jacinta-stacks]

Closes #6817

I am not sure I did this correctly...is this gonna be weird if its a shadow tenure? Not sure if I need to special case that..

[codecov]

Codecov Report

❌ Patch coverage is 72.31183% with 103 lines in your changes missing coverage. Please review.
✅ Project coverage is 68.69%. Comparing base (bc00b29) to head (5370994).
⚠️ Report is 34 commits behind head on develop.

Files with missing lines	Patch %	Lines
stackslib/src/net/api/gettenureblocks.rs	74.50%	39 Missing ⚠️
stackslib/src/net/api/tests/gettenureblocks.rs	48.43%	33 Missing ⚠️
stackslib/src/net/api/gettenureblocksbyhash.rs	65.57%	21 Missing ⚠️
stackslib/src/net/api/gettenureblocksbyheight.rs	86.04%	6 Missing ⚠️
...ackslib/src/net/api/tests/gettenureblocksbyhash.rs	91.66%	2 Missing ⚠️
...kslib/src/net/api/tests/gettenureblocksbyheight.rs	92.00%	2 Missing ⚠️

❌ Your project check has failed because the head coverage (68.69%) is below the target coverage (80.00%). You can increase the head coverage or adjust the target coverage.

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #6818      +/-   ##
===========================================
+ Coverage    67.63%   68.69%   +1.05%     
===========================================
  Files          586      586              
  Lines       362403   357305    -5098     
===========================================
+ Hits        245099   245433     +334     
+ Misses      117304   111872    -5432     

Files with missing lines	Coverage Δ
stacks-common/src/util/hash.rs	84.25% <100.00%> (+4.71%)	⬆️
stackslib/src/chainstate/burn/db/sortdb.rs	80.29% <100.00%> (+5.30%)	⬆️
stackslib/src/chainstate/stacks/db/transactions.rs	79.72% <ø> (-2.26%)	⬇️
...ackslib/src/net/api/tests/gettenureblocksbyhash.rs	95.19% <91.66%> (+95.19%)	⬆️
...kslib/src/net/api/tests/gettenureblocksbyheight.rs	95.04% <92.00%> (+2.36%)	⬆️
stackslib/src/net/api/gettenureblocksbyheight.rs	91.81% <86.04%> (+7.88%)	⬆️
stackslib/src/net/api/gettenureblocksbyhash.rs	81.10% <65.57%> (+71.19%)	⬆️
stackslib/src/net/api/tests/gettenureblocks.rs	35.71% <48.43%> (-56.97%)	⬇️
stackslib/src/net/api/gettenureblocks.rs	83.55% <74.50%> (-3.36%)	⬇️

... and 481 files with indirect coverage changes

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update bc00b29...5370994. Read the comment docs.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[jcnelson]

Instead of loading from the sortition DB's highest known canonical tip, can you instead query relative to the sortition identified by the request's consensus hash? That way, it's unambiguous as to what parent consensus hash is being queried (for example, although unlikely, it is possible that the requested sortition and its parent are both non-canonical, and this change will ensure that the correct parent consensus hash is loaded).

[jacinta-stacks]

Done in c37416b. And then redone in 5370994

[djordon]

So it appears that the GET /v3/tenures/blocks family of endpoints all return an error whenever there are no blocks for a given input. I believe that if I give a bitcoin block height, bitcoin block hash, or consensus hash is known with a winning sortition but had no stacks blocks, these endpoints will return an error. Can we instead have it so that if the given input had a winning sortition but no blocks were produced, that we just given an empty array of stacks blocks "headers" (all while returning the bitcoin block hash, height, consensus hash and last_consensus_ch?

[jacinta-stacks]

So it appears that the GET /v3/tenures/blocks family of endpoints all return an error whenever there are no blocks for a given input. I believe that if I give a bitcoin block height, bitcoin block hash, or consensus hash is known with a winning sortition but had no stacks blocks, these endpoints will return an error. Can we instead have it so that if the given input had a winning sortition but no blocks were produced, that we just given an empty array of stacks blocks "headers" (all while returning the bitcoin block hash, height, consensus hash and last_consensus_ch?

Yep can give it a try. Gotta ruminate a bit because of the way the streaming is set up where it always knows about the next StacksBlockId in the stream. May for e.g. be better to make last_sortition_ch into something like "last_non_empty_sortition_ch"