Do not set err to unwrapped connectErr in error interceptor

[doriable]

This PR removes setting err = connectErr.Unwrap() from our
error interceptor after the connectErr checks. The reason for this
is that this could create some lossiness with err.

For example, when using thread.ParallelizeWithCancelOnFailure,
the errors are appended together with errors.Join:

buf/private/pkg/thread/thread.go

Line 128 in 7321103

return errors.Join(errs...)

When we call errors.As(err, connectErr) in the error interceptor, this matches
the first error in the error tree, in this case the context cancellation, and sets that
as the underlying error. So, when connectErr.Unwrap() is called, only the context
cancellation error is returned, and the rest of err is lost.

[github-actions]

The latest Buf updates on your PR. Results from workflow Buf CI / buf (pull_request).

Build	Format	Lint	Breaking	Updated (UTC)
✅ passed	✅ passed	✅ passed	✅ passed	Dec 12, 2024, 6:19 PM

[bufdev]

There's a reason we did this - do you know what that is? I don't want to undo it without knowing the reason. I believe it was related to UX ie the error message printed out in this case, but maybe not.

[doriable]

So I discussed this with @emcfarlane today, and our thoughts were the reason for this is because connectErr.Unwrap() would remove the connect code from the error message and return the underlying error, e.g. canceled: context canceled -> context canceled. I don't recall any other discussions on this.

The impetus for this change was because there was an issue reported where calling buf generate resulted in a context canceled error because of thread.ParallelizeWithCancelOnFailure. The original err would've returned:

plugin protoc-gen-es: exec: "protoc-gen-es": executable file not found in $PATH
canceled: context canceled

But because we only returned context canceled, it was not easy to debug.