Move config lock check to _load_config

[bewing]

The config lock should always be checked whenever we create a new
configuration session, as we waste compute resources otherwise. If two
NAPALM threads create a session, both will fail to commit with the
current order of operations -- moving the check to session creation
means the first one to obtain the lock will be able to commit.

[bewing]

Partial reversion of #1042 by @blahu

[bewing]

Copy of my comments from slack:

EOS implements sessions in such a way that if you have two open sessions, it's very likely the last one to commit will overwrite the changes from the first.
I was thinking about a workflow where you look at the config, mutate a section of the config, and then commit it back -- there's a race between the first RPC call where I get the config, and the second RPC call where I open the config session with load_merge_candidate
A workaround for this is to just call load_merge_candidate(config=[]) prior to getting the running config to mutate. However, the downside of this is now you could be wasting compute time needlessly. If, for example, I have an extremely low-bandwidth connection to the device, or have to do very heavy computation, it's possible for multiple threads/processes to lock/grab config, as we won't check for locks until the commit. Makes more sense to keep _lock() in _load_config rather than commit_config to me. Thoughts?

[mirceaulinic]

Make sense!