[#2239] writecache: Fix possible deadlock

LRU `Peek`/`Contains` take LRU mutex _inside_ of a `View` transaction.
`View` transaction itself takes `mmapLock` [1], which is lifted after tx
finishes (in `tx.Commit()` -> `tx.close()` -> `tx.db.removeTx`)

When we evict items from LRU cache mutex order is different:
first we take LRU mutex and then execute `Batch` which _does_ take
`mmapLock` in case we need to remap. Thus the deadlock.

[1] 8f4a7e1f92/db.go (L708)

Signed-off-by: Evgenii Stratonikov <e.stratonikov@yadro.com>

pkg/local_object_storage/writecache/storage.go

@@ -23,6 +23,11 @@ type store struct {
 	maxFlushedMarksCount int
 	maxRemoveBatchSize   int
 
+	// flushed contains addresses of objects that were already flushed to the main storage.
+	// We use LRU cache instead of map here to facilitate removing of unused object in favour of
+	// frequently read ones.
+	// MUST NOT be used inside bolt db transaction because it's eviction handler
+	// removes untracked items from the database.
 	flushed simplelru.LRUCache[string, bool]
 	db      *bbolt.DB