feat: Allow specifing how object data is encoded

[achingbrain]

Adds a --data-encoding flag to ipfs object get to let the user specify base64 encoding for object data.

I've found that the text encoding used by default can get mangled during JSON serialisation/deserialisation so using base64 instead seems to make it more resilient.

This allows the test in ipfs-inactive/interface-js-ipfs-core#302 to pass.

--

I've not written much go, so hopefully this PR is ok - I couldn't find much in the way of unit tests around the ipfs object commands though may just have been looking in the wrong place so have added a sharness test.

[schomatis]

LGTM -- the test could be moved to test/sharness/t0051-object.sh.

[achingbrain]

@schomatis done. Do you think it might be worth flipping the default so it outputs base64 by default in the same way that ipfs dag get does?

[schomatis]

Do you think it might be worth flipping the default so it outputs base64 by default in the same way that ipfs dag get does?

Sounds sensible but it would probably break tests that already expect the text as the default format.

[schomatis]

What is up with these Jenkins tests that keep failing for no (apparent) reason?

[achingbrain]

Jenkins is happy now, as is Circle but one of the Travis builds failed and I don't seem to have permissions to re-trigger it.

[schomatis]

It's OK, don't worry about it, the tests are actually passing.

[achingbrain]

Fair enough - I've added a couple more tests to cover text encoding and when an invalid encoding is specified.

[Stebalien]

This is actually a nice, clean, fix. Thanks!

[Stebalien]

@diasdavid this modifies the API, you should take a look.

[daviddias]

@achingbrain thanks for kicking ass! :D mind triple checking by testing with js-ipfs-api and see if everything works well? (you probably already did it, just quadruple check :))

[achingbrain]

@diasdavid I've been using it locally, it all seems fine. It doesn't change the default output, only adds an option for the data encoding so it's not a breaking change.

[achingbrain]

Is there anything else outstanding or can this be merged?

[Stebalien]

This'll make it in after the release (which should happen shortly).

[daviddias]

@Stebalien, what's the ETA calendar wise? This is blocking some of @achingbrain's work on MFS interop.

[Stebalien]

We're planning on cutting a release today, after which we'll merge this. The upside is that the mplex fixes will be released. The downside is that this'll have to wait a day.