Make LargeSmt readers cheap point-in-time snapshots

[huitseeker]

LargeSmt::reader() pairs an upper tree snapshot with a storage reader. A live storage reader can mix an old top with new lower data, as noted in multiple review comments.

So this makes SmtStorage::reader() require a point-in-time snapshot. RocksDbStorage::reader() now returns RocksDbSnapshotStorage, backed by a native RocksDB snapshot, instead of copying the whole database into memory. This addresses this comment. This effectively reverts the tack from #980, which "gave up" on performance considering #873 with the idea that this code, however unused, will tell us what to implement in the node.

The other issue is that reader() cloned the in-memory top, which is large, as noted here. LargeSmt now stores the top as Arc<[Word]>. reader() and clone() share it. Writers use copy-on-write before changing upper nodes.

Also fixes the changelog PR link from #958 to #967

[Mirko-von-Leipzig]

@huitseeker am I understanding that with this we effectively have the ability to acquire a cheap read-only snapshot which won't block writers?

Similar to how databases have a WAL to allow concurrent transactional reads while still writing?

[huitseeker]

@Mirko-von-Leipzig This is the native rocksdb snapshot: https://github.com/facebook/rocksdb/wiki/Snapshot and @sergerad was using it since 77bc5c4 — if only to copy the contents.

Note it does not apply to the top 16-levels of the tree — which aren't in rocksdb — which are CoW, so writers will have to pay an in-memory clone at the time of first write.