replace storer transactions with leveldb batches

[istae]

the chunkstore operations do not currently accept the leveldb batches for writes.
this can cause issues especially in areas of the localstore where the chunkstore is used in tandem with other stores that does indeed utilizes batches for write (eg reserve.Put).

the chunkstore transaction implementation is too complex and bug prone.
transactions for sharky especially is not needed, if a db operation fails, the written data and used slot can simply remain as is and do not need to be recovered.
we have compact cmd now which can give the used sharky space back to the node.

also the reverseOP transaction idea for the indexstore should ideally be completely dropped and all writes must be done using the 'leveldb.batch`.

[istae]

The localstore should ideally looks like this.

The localstore exports core, parent functions like Reserve.Put.
The parent func initiates a Transaction.
Any internal storage calls the parent function makes must utilize the Transaction, and cannot independently make any Writes to the disk directly.

Any two independent parallel writes to the same resource must be mutex locked as a means of data race protection.

The transaction is internally a leveldb.Batch and exposes the storage calls Put, Delete, Get, Commit.
The transaction also exposes the Chunkstore.

Any write ops are accumulated in the batch of the transaction.

Any sharky writes are immediately written to disk.
Sharky releases are kept in memory until the batch is committed.

Here is a summary of the order of operations:
sharky_write -> write to disk, keep write locations in memory
sharky_release -> keep location in memory
batch_write -> write to batch
if batch_commit succeeds -> commit batch to disk, release sharky_release locations in disk
if batch_commit fails, release all sharky_write location from disk, do nothing for sharky_release

[istae]

wrapSync should be removed with a multex in chunkstore ( see storer/reserve.go for what is a multex)

[nikipapadatou]

more discussions are needed between bee team engineers to proceed with this.