Show views from the last save's snapshot on connection threads (080)

The owner publishes a snapshot of the saved states after every save,
before it hands back the answers; connection threads take the newest
one each round and show views from it with a reader app of their own.
A read made after a write's answer sees the write, nothing unsaved or
undone is ever shown, and reads no longer wait while the owner applies
events or syncs. Apps with states always get an owner thread, even
with one connection thread. A round's inputs go to the owner first;
its views are shown and then answered together (answering each one as
it was shown made one thread's 20-row page 8% slower).

On the Pi 5, with 8 connections posting durable scores and 56 reading
the total, reads went from 10-16k/s at p99 13-29 ms to 107-149k/s at
p99 0.6-0.7 ms, and posts stayed in range; axum and drogon, which sync
under their lock, read 1.1-1.3k/s at p99 111-156 ms. A snapshot of a
changed 1,024-item list costs 1.2 us (65,536 items: 87 us) against a
3-4 ms save.

1 files changed, 1 insertions, 1 deletions

diff --git a/benchmarks/http/README.md b/benchmarks/http/README.md
index 3abd431..3672c08 100644
--- a/benchmarks/http/README.md
+++ b/benchmarks/http/README.md
@@ -33,5 +33,5 @@ python3 run.py --module scores.pmod --suite app --rounds 3 --seconds 4 \
 ```
 
 앱 벤치마크의 마지막 작업(`mixed`)은 내구성 점수 POST 8연결과 합계 GET 56연결을 부하 생성기 둘로 함께 보내, 쓰기가
-동기화하는 동안 읽기가 기다리는지 본다. 두 행(posts, reads)으로
+동기화하는 동안 읽기가 기다리는지 본다([080](../../docs/research/080-snapshot-reads.md)). 두 행(posts, reads)으로
 나오고, CPU 1초당 답은 두 행을 합친 것이다.