fix: Avoid lazy-initialized lock

[olleolleolle]

Description

2.10.0 introduced a lock, to synchronize changes to default options.

Issue

The mechanism to obtain the lock tried to wait as long as possible, with a lazy-initialized assignment.

This becomes a race between clients: "Who locks the lock?".

Solution

We avoid this by creating the lock beforehand.

In addition: this changes the lock to be a Mutex, not a Monitor.

A mutex should be fine, the only reason to use a monitor is if you are going to re-enter the same block on the same thread, e.g.

def do_something
 MONITOR.synchronize do
   ...
   yield
   ...
  end
end

def do_something_else
 MONITOR.synchronize do ...

In the above example, the user-supplied block might call another method with the lock.

Generally, "Recursive locks are bad": https://blog.stephencleary.com/2013/04/recursive-re-entrant-locks.html