Improve locking on container.nodes

[anuptalwalkar]

container.nodes map is being used in exported functions that are explicitly locked. We need to improve container locking once #21 is landed. Invoke is taking too long, we don't want to lock the entire dig container.

[glibsm]

Define "too long" and what would make it not "too long".
Do you have a target in mind for how long invoke should take?

[anuptalwalkar]

ok, "too long" may be a loose wording, but essentially we are handing over the container lock to Invoked function for the duration of its execution (resolving dependency will involve executing constructors as well). I am proposing to use locking only when c.nodes is accessed for read/writes instead of locking for entire exported function for Provide, Resolve and Invoke.

[glibsm]

I suggest that we write a benchmark, and consider that this is only happening at service startup. That should give us some ammo to talk about what's "too long".

Locking entire Invoke/Resolve should not be that bad in favor of consistency, but I may be wrong.

This is not something that happens 20k times a second, but rather 10 times on bootup.

[glibsm]

Closing in light of #50
We're going to keep non-concurrent and push those decisions up the stack to whomever is using dig, be that framework or a single user