Use Go 1.20 errors.Join instead of go.uber.org/multierr

[mx-psi]

Go 1.20 includes new builtin error joining support that can replace the usage of go.uber.org/multierr. We should switch to using these and ban the usage of go.uber.org/multierr via depguard (same as this).

[shivanshuraj1333]

@mx-psi kindly assign this one as well

[bogdandrutu]

@mx-psi can you document why we stopped this effort until better understand the performance issue.

[mx-psi]

I removed the good first issue and easy labels and added on hold instead.

The 'easy' way to change the code to use errors.Join means creating a slice of errors, which in the common case will all be nil, and then joining that slice. multierr.Append instead avoids this by checking if the error is nil before adding to the internal slice, which is more performant.

We can still use errors.Join and avoid this by checking that the errors are not nil before appending to the slice, but it leads to more verbose code.

[dmathieu]

Note that errors.Join does check if the error is nil, and skips adding those into the internal slice.
https://github.com/golang/go/blob/a9922d096f0de877fba68739b35367d4c25f6ecb/src/errors/join.go#L33-L35
So I'm not sure we do need to check that errors aren't nil before joining them.

I just proposed this additional patch to the Go team which will optimize the case where a single non-nil error is provided, and it can be returned as-is.
golang/go#70770

[mx-psi]

@dmathieu The patch looks great, thanks for doing this :)

I think the problem I was pointing at above is not addressed by existing code. The problem is the difference between these two:

plainJoin := errors.Join(e1, e2, e3)
nestedJoin := errors.Join(errors.Join(e1, e2), e3)

plainAppend := multierr.Append(e1, e2, e3)
nestedAppend := multierr.Append(multierr.Append(e1, e2), e3)

I believe plainJoin != nestedJoin but plainAppend == nestedAppend. The nested version is pretty common. For example see this code:

opentelemetry-collector/service/service.go

Lines 188 to 198 in 808fb7c

	if err = srv.initGraph(ctx, cfg); err != nil {
	err = multierr.Append(err, srv.shutdownTelemetry(ctx))
	return nil, err
	}
	// process the configuration and initialize the pipeline
	if err = srv.initExtensions(ctx, cfg.Extensions); err != nil {
	err = multierr.Append(err, srv.shutdownTelemetry(ctx))
	return nil, err
	}

Only multierr.Append has this optimization. This is mentioned in golang/go/issues/65676, and was apparently rejected, which means you have to handle the slice creation yourself if you don't want to have this nested structure (which shouldn't matter most of the time but is pressumably less efficient).

[dmathieu]

Yes, errors.Join will keep nesting new structs for each call of errors.Join().
I think Go could possibly still optimize that by detecting that the first error is an *joinError, and using it rather than a new struct.