remove custom trylock in favor of stock sync.Mutex

[chappjc]

Go 1.18 supplements Mutex with a TryLock method. For the on-demand concurrent client accesses to the cache-guarded DB, use this directly instead of our dumb homebrew trylock mutex when Go 1.18 is in use.

IMPORTANT NOTES:

• This change does NOT adopt a new "try lock" pattern. This involves legacy code that had already established this with custom mutex type that has the same new method provided by the sync.Mutex in Go 1.18, so this just uses it.
• While I am aware that proper uses of TryLock are few and far between, the synchronization need here involves controlling access to two data sources, a cache and a DB, where a simple CAS operation is insufficient. In particular, if there is no cached data or if it is stale (by height), a DB query must be launched on-demand, but there must only be one querying goroutine. That part is solvable with a CAS. However, subsequent callers concurrent with the DB updating goroutine (who failed to get the lock or swap) may return stale data, but if there was no cached data they must wait for the DB updater goroutine. While other solutions are readily conceivable for this, the pattern if !TryLock() { if haveCachedData { /* return stale data */ } else { Lock() /* wait */ } } solves this quite handily. This has been functioning well in production for quite some time.

The use case in pseudo code:

// First try the cache for fresh data.
cachedData, stale := checkCache(height)
if !stale {
	return cachedData
}

// Stale data.  Attempt to gain updater status.
if mtx.TryLock() {
	// Query the DB, update cache, and return fresh data.
	...
	return freshData
}
// Another goroutine is running a db query to get the updated data.

if cachedData != nil { // return stale data from cache if we have any
	return cachedData
}

// No stale data available, wait on the DB updater with a full `Lock`
mtx.Lock() // waiting, could also RLock
cachedData, _ := checkCache(height)
return cachedData

An alternative approach that does not involve locking to wait on the data, but rather a channel to receive from, used elsewhere in the project:

dcrdata/db/cache/addresscache.go

Lines 56 to 65 in 429ab90

	// TryLock will attempt to obtain an exclusive lock and a function to release
	// the lock. If the lock is already held, the channel returned by TryLock will
	// be closed when/if the holder of the lock calls the done function.
	//
	// Trylock returns a bool, busy, indicating if another caller has already
	// obtained the lock. When busy is false, the caller has obtained the exclusive
	// lock, and the returned func(), done, should be called when ready to release
	// the lock. When busy is true, the returned channel, wait, should be received
	// from to block until the updater has released the lock.
	func (cl *CacheLock) TryLock(addr string) (busy bool, wait chan struct{}, done func()) {

Also update CI to use go 1.18-beta1.

[ukane-philemon]

Looks straight-forward.

[ukane-philemon]

current version master is v1.55.2, consider updating to v1.58.0

[ukane-philemon]

Can update this the next time you commit.

[ukane-philemon]

This too.

[ukane-philemon]

@dajohi wdyt?