GitLab

This is also done in the Executor. Unfortunately, doing this *here* causes us to
block until we get an argument from stdin, even if we're handling a help call.

forward the remaining of the stdin args to the server

Apparently, it's not thread-safe.

restore Error: prefix

this is a breaking change and many of our tests expect this

prefetch required stdin arguments in CheckArguments

(and test)

Also, make it easier to actually use ParseBodyArguments. Now it only returns an
error when something actually goes wrong.

fix: improve cli/run to return errors and exit code

cleaner command completion/calling

handle both cmdkit.Error and *cmdkit.Error in ChanResponse

**Returning errors/calling:**

Instead of having a dance where we:
  * Close the response emitter immediately if the command succeeds.
  * Return an error, call SetError, and then close the response emitter if it
    fails.

Just set the error from within the `Call` command and always close the response
emitter.

**Doner**

Get rid of the Done channel/doner interface from the response emitter. We close
the response emitter after finishing the Call *anyways* so this channel isn't
necessary (anymore, at least).

fixes https://github.com/ipfs/go-ipfs/issues/4683

Better arrays

testing

Don't handle timeouts in Execute.

Instead, handle it at the boundaries (in ServeHTTP and the CLI's Run function).
This ensures that we actually *wait* to finish writing everything before
canceling the context.

always cancel the request context when calling reqCancel

First check for HEAD request, then error out if writer is nil