Add /v3/contracts/fast-call-read endpoint for (authorized) read only calls without cost tracking

[rdeioris]

This patch adds a new endpoint /v3/contracts/fast-call-read allowing read-only calls to be executed without the cost-tracker.

Given that cost tracking for readonly calls is here mostly for security reasons (avoid run-away calls), the max_execution_time feature of contract calls is automatically enabled (default 30 seconds) and HTTP authorization is required too (not setting the auth-token will basically disable this endpoint) .

The max_execution_time can be configured with the read_only_max_execution_time_secs connection options:

[connection_options]
read_only_max_execution_time_secs = 40

The main reason for this feature is to improve performance of readonly calls (the default cost tracker linearly increases execution times based on the clarity code complexity).

Description

Applicable issues

• Analyze and improve performance of readonly contract calls #6190

Additional info (benefits, drawbacks, caveats)

Checklist

• Test coverage for new or modified code paths
• Changelog is updated
• Required documentation changes (e.g., docs/rpc/openapi.yaml and rpc-endpoints.md for v2 endpoints, event-dispatcher.md for new events)
• New clarity functions have corresponding PR in clarity-benchmarking repo
• New integration test(s) added to bitcoin-tests.yml

[rdeioris]

@kantai as discussed in the nakameeting it does not make too much sense to allow the user to decide about the cost tracking strategy. At this point is not better to just use free cost tracking and enforce max_execution time ? this will result in faster readonly calls "by default" and zero work for builders/users

[Jiloc]

If I am not mistaken, the FreeCostTracker doesn't even track memory usage. Could a read-only operation potentially consume significant memory? If so, we might consider implementing a third cost tracker option, something like "MemoryOnly"—that would track memory consumption while still returning zero for runtime costs.

Regarding how to handle the choice between Limited and MemoryOnly trackers: since using FreeTracker can be a security risk, we could restrict the cost_tracker= parameter to authenticated requests only (similar to our current implementation in /v3/block_proposal and /v3/blocks/upload). This would allow trusted clients to specify their preferred tracker while forcing untrusted clients to use the Limited tracker by default

[Jiloc]

Just missing the timeout error in the open api spec, everything else lgtm!

[Jiloc]

lgtm!

[obycode]

LGTM!

[codecov]

Codecov Report

Attention: Patch coverage is 89.29889% with 58 lines in your changes missing coverage. Please review.

Project coverage is 76.63%. Comparing base (bc58a1e) to head (997c318).
Report is 19 commits behind head on develop.

Files with missing lines	Patch %	Lines
stackslib/src/net/api/tests/fastcallreadonly.rs	87.80%	30 Missing ⚠️
stackslib/src/net/api/fastcallreadonly.rs	91.30%	20 Missing ⚠️
stackslib/src/net/http/error.rs	52.94%	8 Missing ⚠️

❌ Your project status has failed because the head coverage (76.63%) 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    #6207       +/-   ##
============================================
+ Coverage    45.49%   76.63%   +31.13%     
============================================
  Files          536      543        +7     
  Lines       343845   345656     +1811     
  Branches         0      323      +323     
============================================
+ Hits        156439   264896   +108457     
+ Misses      187406    80752   -106654     
- Partials         0        8        +8     

Files with missing lines	Coverage Δ
stackslib/src/config/mod.rs	70.80% <100.00%> (+20.77%)	⬆️
stackslib/src/net/api/callreadonly.rs	93.27% <ø> (+27.80%)	⬆️
stackslib/src/net/api/mod.rs	92.42% <100.00%> (+0.48%)	⬆️
stackslib/src/net/api/tests/mod.rs	89.22% <100.00%> (+9.80%)	⬆️
stackslib/src/net/connection.rs	79.02% <100.00%> (+23.70%)	⬆️
stackslib/src/net/http/mod.rs	51.02% <ø> (+6.12%)	⬆️
stackslib/src/net/httpcore.rs	81.88% <100.00%> (+8.76%)	⬆️
stackslib/src/net/http/error.rs	50.37% <52.94%> (+0.58%)	⬆️
stackslib/src/net/api/fastcallreadonly.rs	91.30% <91.30%> (ø)
stackslib/src/net/api/tests/fastcallreadonly.rs	87.80% <87.80%> (ø)

... and 427 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 bc58a1e...997c318. 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.

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.