Make the image load lock configurable per runtime

[afbjorklund]

The container runtimes that have a central server daemon to
coordinate loads, don't need to lock image load at each client.

We still need to limit the number of simultaneous loads for
runtimes that load directly, in order to not run of resources.

Closes #6992

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: afbjorklund

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [afbjorklund]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[tstromberg]

Alternatively, what do you think about runtimes being specify a maximum number of simultaneous loads?

I theorize that 1 is not likely to be the right answer for any, but neither is 20.

[afbjorklund]

@tstromberg, yes we could at least add that to the "API" (i.e. change from a bool to an int)

I think there was a neat class for it, change the sync.Mutex for a thread pool / worker pool ?

[tstromberg]

@tstromberg, yes we could at least add that to the "API" (i.e. change from a bool to an int)

I think there was a neat class for it, change the sync.Mutex for a thread pool / worker pool ?

I wouldn't call it a neat class, but It is not difficult to implement with buffered channels: https://gist.github.com/AntoineAugusti/80e99edfe205baf7a094

Alternatively, there are a handful of libraries which have packaged this up:

https://github.com/korovkin/limiter
https://github.com/sirsean/go-pool
https://github.com/nozzle/throttler

[tstromberg]

Need any help with this PR?

[afbjorklund]

Need any help with this PR?

Yes, I was only trying to speed up the Docker case - haven't looked at the other ones (or pooling)

[afbjorklund]

I will not have the time to implement this "properly", so will close the simple attempt (this PR)