This is a follow-up to 7ede40c, where we pinned
the version of this dependency to prevent go modules rolling it back.

This patch updates the version to use the merge-commit that merged the v1.0
release branch back to the main branch in github.com/opencontainers/image-spec,
so that go modules considers it "more recent" and doesn't roll back.

Updating does not introduce changes in the vendored code, as changs of the merged
commits were either already in the main branch, or only affected non-code files.

- full diff: opencontainers/image-spec@693428a...c5a74bc
- raw diff: https://github.com/opencontainers/image-spec/compare/693428a734f5..c5a74bcca799

Thanks to Tõnis Tiigi for pointing to this commit!

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>

[release/1.6] go.mod: update image-spec to merge-commit of v1 into main

The Collector.Collect will be the field ns'Collect's callback, which be
invoked periodically with internal lock. And Collector.Add also runs
with ns.Lock in Collector.Lock, which is easy to cause deadlock.

Goroutine X:

	ns.Collect
	  ns.Lock
	    Collector.Collect
	      Collector.RLock

Goroutine Y:

	Collector.Add
	  Collector.Lock
	    ns.Lock

We should use ns.Lock without Collector.Lock in Add.

Fix: #6772

Signed-off-by: Wei Fu <fuweid89@gmail.com>
(cherry picked from commit 8a1280b)
Signed-off-by: Wei Fu <fuweid89@gmail.com>

[release/1.6] metrics/cgroups: fix deadlock issue in Add during Collect

(cherry picked from commit 147f0a7)
Signed-off-by: Mike Brown <brownwm@us.ibm.com>

[release/1.6] check for duplicate nspath possibilities

go1.17.9 (released 2022-04-12) includes security fixes to the crypto/elliptic
and encoding/pem packages, as well as bug fixes to the linker and runtime. See
the Go 1.17.9 milestone on the issue tracker for details:

Includes fixes for:

- CVE-2022-24675 (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-24675)
- CVE-2022-28327 (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-28327)

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>

[release/1.6] update golang to 1.17.9

Background:

With current design, the content backend uses key-lock for long-lived
write transaction. If the content reference has been marked for write
transaction, the other requestes on the same reference will fail fast with
unavailable error. Since the metadata plugin is based on boltbd which
only supports single-writer, the content backend can't block or handle
the request too long. It requires the client to handle retry by itself,
like OpenWriter - backoff retry helper. But the maximum retry interval
can be up to 2 seconds. If there are several concurrent requestes fo the
same image, the waiters maybe wakeup at the same time and there is only
one waiter can continue. A lot of waiters will get into sleep and we will
take long time to finish all the pulling jobs and be worse if the image
has many more layers, which mentioned in issue #4937.

After fetching, containerd.Pull API allows several hanlers to commit
same ChainID snapshotter but only one can be done successfully. Since
unpack tar.gz is time-consuming job, it can impact the performance on
unpacking for same ChainID snapshotter in parallel.

For instance, the Request 2 doesn't need to prepare and commit, it
should just wait for Request 1 finish, which mentioned in pull
request #6318.

```text
	Request 1	Request 2

	Prepare
	   |
	   |
	   |
	   |		Prepare
	Commit		   |
			   |
			   |
			   |
			Commit(failed on exist)
```

Both content backoff retry and unnecessary unpack impacts the performance.

Solution:

Introduced the duplicate suppression in fetch and unpack context. The
deplicate suppression uses key-mutex and single-waiter-notify to support
singleflight. The caller can use the duplicate suppression in different
PullImage handlers so that we can avoid unnecessary unpack and spin-lock
in OpenWriter.

Test Result:

Before enhancement:

```bash
➜  /tmp sudo bash testing.sh "localhost:5000/redis:latest" 20
crictl pull localhost:5000/redis:latest (x20) takes ...

real	1m6.172s
user	0m0.268s
sys	0m0.193s

docker pull localhost:5000/redis:latest (x20) takes ...

real	0m1.324s
user	0m0.441s
sys	0m0.316s

➜  /tmp sudo bash testing.sh "localhost:5000/golang:latest" 20
crictl pull localhost:5000/golang:latest (x20) takes ...

real	1m47.657s
user	0m0.284s
sys	0m0.224s

docker pull localhost:5000/golang:latest (x20) takes ...

real	0m6.381s
user	0m0.488s
sys	0m0.358s
```

With this enhancement:

```bash
➜  /tmp sudo bash testing.sh "localhost:5000/redis:latest" 20
crictl pull localhost:5000/redis:latest (x20) takes ...

real	0m1.140s
user	0m0.243s
sys	0m0.178s

docker pull localhost:5000/redis:latest (x20) takes ...

real	0m1.239s
user	0m0.463s
sys	0m0.275s

➜  /tmp sudo bash testing.sh "localhost:5000/golang:latest" 20
crictl pull localhost:5000/golang:latest (x20) takes ...

real	0m5.546s
user	0m0.217s
sys	0m0.219s

docker pull localhost:5000/golang:latest (x20) takes ...

real	0m6.090s
user	0m0.501s
sys	0m0.331s
```

Test Script:

localhost:5000/{redis|golang}:latest is equal to
docker.io/library/{redis|golang}:latest. The image is hold in local registry
service by `docker run -d -p 5000:5000 --name registry registry:2`.

```bash

image_name="${1}"
pull_times="${2:-10}"

cleanup() {
  ctr image rmi "${image_name}"
  ctr -n k8s.io image rmi "${image_name}"
  crictl rmi "${image_name}"
  docker rmi "${image_name}"
  sleep 2
}

crictl_testing() {
  for idx in $(seq 1 ${pull_times}); do
    crictl pull "${image_name}" > /dev/null 2>&1 &
  done
  wait
}

docker_testing() {
  for idx in $(seq 1 ${pull_times}); do
    docker pull "${image_name}" > /dev/null 2>&1 &
  done
  wait
}

cleanup > /dev/null 2>&1

echo 3 > /proc/sys/vm/drop_caches
sleep 3
echo "crictl pull $image_name (x${pull_times}) takes ..."
time crictl_testing
echo

echo 3 > /proc/sys/vm/drop_caches
sleep 3
echo "docker pull $image_name (x${pull_times}) takes ..."
time docker_testing
```

Fixes: #4937
Close: #4985
Close: #6318

Signed-off-by: Wei Fu <fuweid89@gmail.com>
(cherry picked from commit 8113758)
Signed-off-by: Davanum Srinivas <davanum@gmail.com>

When support for http/protobuf was added, the OTLP tracing processor
plugin was mistakenly changed to return a raw OTLP exporter instance.
Consequently, the type-assertion to a trace.SpanProcessor inside the
tracing pluigin would panic if the processor plugin was configured.
Modify the OTLP plugin to return a BatchSpanProcessor derived from the
exporter once more.

Signed-off-by: Cory Snider <csnider@mirantis.com>
(cherry picked from commit 927b34e)
Signed-off-by: Kazuyoshi Kato <katokazu@amazon.com>

[release/1.6] tracing: fix panic on startup when configured

Signed-off-by: Derek McGowan <derek@mcg.dev>

Prepare release notes for v1.6.3