Provide response body in the HTTP API for /api/v0/files/write endopint

[Gozala]

Unlike /api/v0/add endpoint that produces following response body on success:

{
  "Bytes": "<int64>",
  "Hash": "<string>",
  "Name": "<string>",
  "Size": "<string>"
}

Endpoint for /api/v0/files/write produces no results. Which happens to be at odds with js-ipfs files.write that returns {cid, size} pair.

There had being recent discussion about this mismatch between (See: ipfs/js-ipfs#3055 (comment)) HTTP-API and JS-IPFS API. While JS-IPFS could drop return value, I think it would be more useful to change HTTP-API to produce response body instead. I for one recall having to do two HTTP calls in the past to overcome this exact limitation.

[lidel]

@Stebalien is there a hard requirement that we don't return anything in response to /api/v0/files/write ?

Given the fact more and more people use HTTP API (not just ipfs CLI),
I would go as far as marking lack of CID in response as UX bug.

Would a PR adding response (cid, perhaps size?) be accepted?
(js-ipfs is ok to go either way, as long go-ipfs decides)

[Stebalien]

I think we didn't return a CID so we could produce it lazily on demand. On the other hand, the current HTTP API isn't going to work for performance sensitive operations anyways. For that, we'll likely want an actual RPC API, with file handles and such.

TL;DR: Go ahead. However, we should probably avoid returning a CID if --flush=false is passed.