Potential collision and risk from indirect dependency onsi/ginkgo

# Description
google/trillian has already opted into module and indirectly depends on onsi/ginkgo through a GOPATH project. And project onsi/ginkgo already opted into module and released a v2+ version with the major branch strategy. The latest module path of onsi/ginkgo is "github.com/onsi/ginkgo/v2" . From module-unaware project\'s perspective, it interprets the import path "github.com/onsi/ginkgo" as onsi/ginkgo\'s latest version. But from the Go Modules\' point of view, path "github.com/onsi/ginkgo" equals to version v0/v1 or the latest version that doesn’t use the module. So when you try to get onsi/ginkgo through the indirect path "github.com/onsi/ginkgo" which comes from module-unaware project, the module pulls the old version of onsi/ginkgo. This causes version of onsi/ginkgo , which you are dependent on, sticked at the old version onsi/ginkgo .
Same to these indirect dependencies:.

# Possible solution
Add a replace directive in your go.mod files with version information to avoid sticking at the old version.