chore(pkg/database): use atomic for waitingCount in instrumentedRWMutex

[arturmelanchyk]

This change minimizes lock contention when working with instrumentedRWMutex
According to the attached benchmark Lock \ Unlock operations as well as RLock \ RUnlock gain ~50% performance boost while State's performance remains on the same level

[tomekkolo]

I do not think that it makes sense to use defer here, just call after rlock.

[arturmelanchyk]

fixed

[tomekkolo]

@arturmelanchyk , please sign commits with GPG

[arturmelanchyk]

Just a kind reminder @tomekkolo @SimoneLazzaris , branch has been rebased onto latest master and all commits signed with GPG

[tomekkolo]

Just a kind reminder @tomekkolo @SimoneLazzaris , branch has been rebased onto latest master and all commits signed with GPG

Looked at it once more, why using 64 bit ? If you follow the path where it is used (DatabaseHealth), it is anyway cut to 32bits at the end. And generally, no need for such big counter here. Also not sure about real gain, this endpoint is not called so much.

[arturmelanchyk]

@tomekkolo

1. As to the real gain, database heavily rely on this instrumentedRWMutex type, its used everywhere instead of regular sync.Mutex and sync.RWMutex
   

   immudb/pkg/database/database.go

   Lines 147 to 153 in c7265c6

   	type db struct {
   	st *store.ImmuStore
   	sqlEngine *sql.Engine
   	documentEngine *document.Engine
   	mutex *instrumentedRWMutex

see list of methods that use it:

as a result, even tiny improvement in this type will lead to noticeable speed boost

2. As to the size, instance of this type is only created once, so comparing 32bit to 64 bit we would only save 32bits once. Also take into consideration that in previous version this type was int which would anyway compile to 64 bits on most of the modern computers, so technically we do not add anything. Moreover, due to how golang aling structs in memory in this specific case it will anyway use 64bit, not 32, even if you change the type to 32bit