rename and update mergo module

[acim]

- What I did

I renamed module github.com/imdario/mergo to dario.cat/mergo and updated to the latest version. This fixes #4377.

- How I did it

I renamed the import in merge.go and merge_test.go and ran make vendor.

- How to verify it

Run tests.

- Description for the changelog

- A picture of a cute animal (not mandatory but encouraged)

[codecov-commenter]

Codecov Report

Merging #4378 (b32264a) into master (605942c) will not change coverage.
The diff coverage is n/a.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #4378   +/-   ##
=======================================
  Coverage   59.29%   59.29%           
=======================================
  Files         288      288           
  Lines       24769    24769           
=======================================
  Hits        14687    14687           
  Misses       9198     9198           
  Partials      884      884           

[thaJeztah]

Thanks! I'm wondering what motivated the move to a vanity URL; I hope there's good hosting behind it, as I've had bad experience with vanity URLs not always being very reliable

[acim]

Well, I don't know, I am not the author/maintainer of that module. Since you are using vendoring it is probably not that unsafe.

[neersighted]

It's not quite inherently safe since we do (among other things) check that vendoring is correct in CI, which requires network access to the module source code. That being said, we should allow GOPROXY for that -- in the past we had it disabled for $REASONS, but it is designed to solve this problem (validation/fetching of code already in your go.sum).

Basically, any issues we have are largely self-inflicted and we can work them out. LGTM!

[thaJeztah]

Yeah, it's definitely not a blocker, just bad experience with vanity URLs going AWOL. While GOPROXY is useful for temporary downtime of those, it's not a permanent fix; I've had situations where vanity URLs actually went down (permanently), in which case it's a ticking time bomb until GOPROXY's cache expires. Of course using the upstream code repository (github.com) does not help for situations where project source is actually removed, but for other cases I have more trust in github.com's availability / SLA, than domains hosted by a single individual.

[thaJeztah]

LGTM

[darccio]

@thaJeztah Allow me to indicate that the hosting is CloudFlare, and I plan to keep the domain. It shouldn't be an issue.