chore: prepare release 2.11.0

[github-actions]

This PR was created automatically. Merging it will finalize the changelog for 2.11.0

Features

Index unreferenced sectors for pruning

Sectors now track how many contract and temp storage references they have, and
a location holds a lock while a sector is being written to it. The prune sweep
reads unreferenced sectors from an index instead of scanning every stored
sector, which on a 100 TiB host held the database for about six seconds every
five minutes. The last access timestamp is removed. The upgrade computes the
counts for existing sectors and rewrites the sector table, which takes about a
minute at that size.

Fixes

• Allow concurrent database reads
• Fix high CPU usage during sector pruning
• Sector migration no longer holds the database lock while copying data
• Removed the in-memory sector cache, the sectorCacheSize setting is now ignored
• Reverted back to encoding/json from sonic.
• Update go.sia.tech/coreutils to v0.24.1

Fix the merkle cache bloating the stored sectors table

The cache kept 32 KiB of subtree roots inline on every sector row, which slowed
sector reads, pruning and contract root lookups. Cached roots are discarded on
upgrade and rebuilt on the next read.

[FloGerl]

Just adding an operational data point in case it helps prioritize this release: on v2.10.3 my host is currently becoming effectively unusable after some runtime. The Web UI becomes inaccessible and restarting only resets the problem temporarily.

The hostd SQLite DB is already on a Micron 5210 SATA SSD. During the failure state I'm seeing roughly 3,300–4,600 × 4–5 KiB reads/s, 70–83% SSD utilization, around 22% Linux I/O PSI full avg60, and hostd's Linux OS thread count growing from around 17 after restart to 1,800+; the previous instance reached 5,467 threads.

The workload has also been remarkably consistent, reading around 72–74 GB/hour. Given that #993 is included in this 2.10.4 release PR and appears directly relevant to the SQLite access pattern, this looks like a very strong candidate for the issue I'm seeing.

Based on the symptoms and the storage profile, I strongly suspect the fix in #993 will resolve the situation. Since the corresponding code is already merged and included in this release PR, I'd very much appreciate it if v2.10.4 could be released as soon as reasonably possible so I can verify that in production.

Happy to provide additional measurements or test a build if useful.

[Superassi]

Since 2.10.3 I'm haven the same issues like FloGerl and the instance is nearly unusable, Webservice is often unavailable, there are every 6-8min peaks with the storage up to 100GB/h and the instance is often not responding to the sianetwork

Just adding an operational data point in case it helps prioritize this release: on v2.10.3 my host is currently becoming effectively unusable after some runtime. The Web UI becomes inaccessible and restarting only resets the problem temporarily.

The hostd SQLite DB is already on a Micron 5210 SATA SSD. During the failure state I'm seeing roughly 3,300–4,600 × 4–5 KiB reads/s, 70–83% SSD utilization, around 22% Linux I/O PSI full avg60, and hostd's Linux OS thread count growing from around 17 after restart to 1,800+; the previous instance reached 5,467 threads.

The workload has also been remarkably consistent, reading around 72–74 GB/hour. Given that #993 is included in this 2.10.4 release PR and appears directly relevant to the SQLite access pattern, this looks like a very strong candidate for the issue I'm seeing.

Based on the symptoms and the storage profile, I strongly suspect the fix in #993 will resolve the situation. Since the corresponding code is already merged and included in this release PR, I'd very much appreciate it if v2.10.4 could be released as soon as reasonably possible so I can verify that in production.

Happy to provide additional measurements or test a build if useful.