[Merged by Bors] - Create separate connection to state DB for API

[kacpersaw]

Description

This pull request introduces a separate SQL connection pool for the API interface. This change aims to isolate the API's database interactions from the main application pool to prevent exhausting all connections.

Closes #5583

[codecov]

Codecov Report

Attention: Patch coverage is 87.50000% with 4 lines in your changes missing coverage. Please review.

Project coverage is 81.7%. Comparing base (a5c856c) to head (30645cf).
Report is 3 commits behind head on develop.

Files with missing lines	Patch %	Lines
node/node.go	82.6%	2 Missing and 2 partials ⚠️

Additional details and impacted files

@@            Coverage Diff            @@
##           develop   #6386     +/-   ##
=========================================
- Coverage     81.7%   81.7%   -0.1%     
=========================================
  Files          315     315             
  Lines        35057   35077     +20     
=========================================
+ Hits         28653   28664     +11     
- Misses        4568    4574      +6     
- Partials      1836    1839      +3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[fasmat]

Is this safe to do? I know the API opens the DB readonly, but the node changes the data in the DB.

What happens if data is changed by the node while the API reads from the DB? Like inserting ATXs while API queries those ATXs?

[ivan4th]

What happens if data is changed by the node while the API reads from the DB? Like inserting ATXs while API queries those ATXs?

If there's a long-running SELECT than write transaction will not begin until it ends
There can be situation where writes can happen between several reads but given the writes that may happen are "append-only" I don't immediately see a possibility for inconsistencies.
If there's such a possibility we need to use read transactions, but this is not supported by sql/database currently, as all the transactions started are actually immediate (they acquire write lock immediately). Note that long-running read transactions will block writes (causing SQLITE_BUSY), though.

EDIT: I made this mistake again in this comment, sorry :)
We use WAL and read transactions do no block writes. Read transactions only block WAL checkpointing.
But there can be only one active write transaction at a given moment.

[ivan4th]

Updated my comment above b/c I made a mistake in it regarding db locking

[ivan4th]

(but this doesn't block this PR, it's ok to merge)

[kacpersaw]

bors merge

[spacemesh-bors]

Pull request successfully merged into develop.

Build succeeded:

• ci-status
• systest-status