refactor(cmds): do not return errors embedded in result type

[gammazero]

Asynchronous functions should return errors over channels instead of embedding the error in the result type.

Closes #9974

[gammazero]

This is implemented to operate on any UnixfsAPI since their Ls should all work the same. Is this a good assumption / implementation, or should each UnixfsAPI provide its own LsIter?

[hsanjuan]

I guess it doesn't hurt, but it not used?

[hsanjuan]

LGTM although improvement is marginal if this was already working code, with the side effect of altering CoreAPI (not sure if anyone builds anything on top of it other than Kubo itself).

I personally don't like the new pattern much more than the old one. Something like pin.Ls(...) (chan, chan) launches a goroutine and returns a channel:

• The channel is chosen to be unbuffered even though it has no idea what the user wants it for.
• Goroutine is hidden inside so that the user-code looks sync when it's async. Context management becomes important. One must not forget to finish reading or cancelling etc.

For me, the best pattern would be APIs like pin.Ls(chan Pins) err, where the user passes the channel on which they want the results written. The Ls function is all sync, it writes pins to the given channel, and when done closes the channel and sets the error. This forces goroutine/channel management fully onto the caller, which can choose how to buffer things etc. i.e.:

   out := make(chan Pins, 1000)
   make errCh := make(chan error, 1)
   go func() {
     defer close(errCh)
     errCh <- pin.Ls(ctx, out)
   }
   for p := range out {
     printPin(p)
   }
   err = <- errCh
   return err

The implementation of pin.Ls() does not need to allocate goroutines or channels, it can work fully in sync-mode by writing to a channel until something fails or its done, and the user can choose whether it wants to buffer or not.

Anyways this is just passing work around our own internal code, so it's all mostly the same.

[gammazero]

Thank you for the review. This PR was a much as a exploration to find a more preferable pattern as to satisfy the original issue. I really agree with

it can work fully in sync-mode by writing to a channel until something fails or its done, and the user can choose whether it wants to buffer or not.

and also, let the caller decide whether or not the function should be called asynchronously.

The one benefit this PR does have is not having to wait on both ctx and err chan in case err chan is not read, but that is not really important with regart to the above statement. I will take another pass over this to incorporate your feedback.

[hsanjuan]

I think everything has become much nicer to read.

[hsanjuan]

I guess it doesn't hurt, but it not used?