GitLab

Apparently, windows returns "invalid file handle" and golang doesn't translate
this to EINVAL.

fixes ipfs/go-ipfs#6021

We inserted these while transitioning to the new API but we've never hit one.

It wasn't a reliable way to determine if the command was "done". We need to wait
for run, post-run, etc. to finish first.

* Fixes #143

This commit:

1. Removes the exit channel from the CLI response emitter.
2. Adds a `Status()` function to the `cli.ResponseEmitter` as a replacement
   for (1).
3. Renames `Exit(code)` to `SetStatus(code)`. This new function doesn't
   immediately _do_ anything other than set the status.
4. Make sure to wait for _everything_ to finish before returning from `cli.Run`.

*Don't* say "context canceled". Just say "canceled".

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

This time, we completely separate error encoding and let the emitter deal with it. Basically:

1. Some transports won't even use the same channel.
2. We don't *have* an error "encoder" for protobuf.

We now *finally* return the correct content type (json) when returning an error after passing `--enc=protobuf`.

This *also*:

1. Removes GetDecoder. We need to special case this every time anyways.
2. Allows transports to specify the "default" encoding type instead of assuming JSON.
3. Ensure that we never mistake a value for an error in the HTTP transport by converting to a cmdkit.Error *before* passing errors to `doPreamble`.

Only use custom encoders for values.

fixes #65

Also, remove SetEncoder. Always derive the correct encoder from the request.

- remove HandleError() because we now have CloseWithError
- remove Header interface
- remove all Head() methods
- fix locking in chan.go
- use EmitChan in ResponseEmitters
- introduce cmds.ErrClosedEmitter
- fix tests (some still expected errors to be emitted/marshaled)

We can add these back if we need them but, at the very least, we shouldn't be
unconditionally generating stack traces on `Close`.