Use separate mutex for locked outputs

[peterjan]

This PR reverts a change we made that introduced a deadlock in the locking behaviour. Instead of keeping the tip in memory, we return it from the store alongside the unspent elements. It also improves the overall locking by covering the fetching of unspent element under the lock as well.

[n8maninger]

This feels like somewhere is calling a wallet method that locks the mutex within the open db transaction rather than an issue with the internal locking. The locking is fairly intentional to prevent invalid proofs. I'd rather not change it unless we're confident it's not breaking something else.

[ChrisSchinnerl]

This feels like somewhere is calling a wallet method that locks the mutex within the open db transaction rather than an issue with the internal locking. The locking is fairly intentional to prevent invalid proofs. I'd rather not change it unless we're confident it's not breaking something else.

The obvious candidate is UpdateChainState. Because usually the SingleAddressWallet first acquires mu and then opens a database transaction. e.g. in FundV2Transaction it first locks the mutex and then locks the outputs in the store while holding the mutex. In UpdateChainState the transaction is already open and then it acquires mu.

So all it takes is for one goroutine to try and open a database transaction while holding the wallet lock and another one acquiring the wallet lock from within an open database connection. Which could in theory happen now if FundV2Transaction and UpdateChainState are called rapidly in parallel.

[peterjan]

Renter tests are 🟢 - verified here https://github.com/SiaFoundation/renterd/pull/1896/checks