[RFC] Remove custom multierrors package

[thaJeztah]

What I did

The hashicorp/go-multierror package provides functionality to do this. Replacing the custom package in favor of those (at the cost of some small duplication).

Removing the custom package will prevent our implementation to diverge from the upstream. Alternatively, we could fully implement our own "multi error" package (instead of using the hashicorp package), which could be a simplified version that only provides what we need, but we'd have to maintain that.

Also added a nil-check to prevent a potential panic if multierror was nil

Related issue
<-- If this is a bug fix, make sure your description includes "fixes #xxxx", or "closes #xxxx" -->

(not mandatory) A picture of a cute animal, if possible in relation with what you did

[thaJeztah]

Should we produce an error in the --force case, or only warn (and skip)? At least --force should ignore none-existing contexts (and have a "zero" exit code)

There may be some incorrect behaviour in the old CLI in this respect (noticed some in docker volume rm)

[thaJeztah]

Actually, I recall there was some discussion about this, and it should only be a "success" in the "not exists" situation; see docker/cli#394

docker volume create namedvol
docker volume rm namedvol nosuchvolume
# namedvol
# Error: No such volume: nosuchvolume

echo $?
# 1

docker volume create namedvol
docker volume rm --force namedvol nosuchvolume
# namedvol
# nosuchvolume

echo $?
# 0

[rumpl]

Ah right, the --force shouldn't return 0 no matter what

[thaJeztah]

I think (looking at the other discussion) it should still error if there's a failure to remove, but should ignore cases where the context doesn't exist, so perhaps removeContext needs a force argument so that it can ignore the "does not exist" case.

[rumpl]

Right, any ideas to how we can avoid the boolean trap?

[rumpl]

The custom mutlierror was there for a nicer output than the one the original package has, I wrote on this PR but no response yet :/

How is the output now?

[thaJeztah]

The custom mutlierror was there for a nicer output than the one the original package has, I wrote on this PR but no response yet :/

Ah, right; that was the first approach I took, but instead of keeping the multierror package, I took the approach from the go-multierror example in their readme;

if errs != nil {
	errs.ErrorFormat = listFormatFunc
}

I sill think that would be a good alternative for now (so that we don't have to maintain our own multi error package). Given that it's currently only used in two locations, I don't think it'd be a huge issue to have those lines in those two locations.

How is the output now?

With this, it should look something like:

package main

import (
	"fmt"

	"github.com/hashicorp/go-multierror"
)

func main() {
	fmt.Println(foo())
}

func foo() error {
	var errs *multierror.Error
	errs = multierror.Append(errs, multierror.Prefix(fmt.Errorf("cannot delete current context"), "Error:"))
	errs = multierror.Append(errs, multierror.Prefix(fmt.Errorf("cannot delete current context"), "Error:"))
	errs = multierror.Append(errs, multierror.Prefix(fmt.Errorf("cannot delete current context"), "Error:"))	
	return errs.ErrorOrNil()
}

Which outputs https://play.golang.org/p/qlRMR2cF0AV

3 errors occurred:
	* Error: cannot delete current context
	* Error: cannot delete current context
	* Error: cannot delete current context

(so there will be a difference, as it adds the 3 errors occurred:)

[rumpl]

Fair enough, it's not used that much so it's ok to just use hashicorp's mutlierror.

[thaJeztah]

Let me know if you want the format to be updated, then I can take the other approach instead

[rumpl]

Let me know if you want the format to be updated, then I can take the other approach instead

Yeah to think of it, let's define our list function right away that way the output doesn't change once the PR is merged over at go-multierror

[rumpl]

LGTM

[rumpl]

@thaJeztah could you please rebase with main?

[thaJeztah]

Rebased 👍

[rumpl]

Thank you