Backwards compatible pure data model API

[Gozala]

This pull request attempts to add pure Data Model API interop (as per #173) in a backwards compatible way. High level overview of the changes are:

• Getters / Setters are replaced by non-writable public properties.
• Some internal ops that add / remove links do mutate arrays in place instead of swapping arrays (due to introduce non-writable constraint).
• serialization code now handles ArrayBuffer and TypedArray for node.Data.

Only visible change is that node.Links no longer returns links mapped to pure data, but rather DAGLink instances. However it should not matter in practice because those were made to behave just like pure data would. Although tests had to be change to use .containSubset instead of .eql because later fails when prototype chain is different.

[vmx]

Wow, nice work. I just tested it also with js-ipld and it just worked. If @achingbrain is happy with those changes, I don't see a reason for not making those changes.

[achingbrain]

This is great, just a few small points.

[Gozala]

Summary of few updates I've made:

1. Pull chai from aegir.
2. Remove Uint8Array to Buffer casting in favor of doing it in protons (See feat: support Uint8Array input in place of Buffer ipfs/protons#13)

• Current patch changes protons dep to point to my fork. Once it lands and published I'll update this to point to new verison.
• ArrayBuffer as Data is no longer supported, it's just Uint8Array now. Mostly to keep things simple on protons side.

3. Replaced immutable sortLinks with mutable version. Immutable version was not used anywhere else in this package.

[rvagg]

Seems good to me (once the protons dep is updated, and I wouldn't mind seeing consistency retained with arrow function parens as per notes I've left). I hope we have solid integration tests covering all of this when it propagates upward!

[Gozala]

@achingbrain I believe I've addressed all your comments and comments from @rvagg. @vmx I hope you agree with my arguments to decouple this from switch to https://github.com/mapbox/pbf, I do not know what errors may arise from that change & I do not want to block my primary work on that.

Please let me know if there is anything else to be done, or if this can land.

Thanks

[rvagg]

👌 very nice work

this will probably have to wait for @vmx to return from vacation to get published, unless there's some urgency

[Gozala]

@vmx any chance you could get to this sometime this week ? I can't make any more progress on ipfs/js-ipfs#3081 without this.

[vmx]

@Gozala any objections if I release this as 0.19? It's been quite a big change and I don't want to have regressions sneaked it.

[Gozala]

@vmx that sounds good to me. Thanks