Separation of core and helper methods

[acruikshank]

closes #7

Motivation

The fetcher adds many functions to fetch IPLD prime through IPFS. Most of these methods are simply conveniences to provide a simple interface for common tasks. This proliferation of methods will complicate future efforts to extend or replace this library. A better pattern is to provide a few very flexible methods to provide core functionality (fetcherSession), give it an interface, then call the rest helper methods and modify them to use this interface.

Note: The issue discussed limiting the core to BlockMatchingOfType and NodeMatching. Arguably, BlockOfType is more core than BlockMatchingOfType and in practice either of these requires significant additional complexity to implement from the other (I tried it both ways). Consequently, I've left both BlockOfType and BlockMatchingOfType in the core.

What's in this PR

1. Add Fetcher interface for core methods, and rename Fetcher struct to fetcherSession.
2. Modify all methods outside core to be free functions that take a Fetcher as a parameter.
3. Add tests for all functions not already covered.
4. After comments from @warpfork and the discovery of a race condition in the tests, convert the return from 2 channels to 1 channel with an error field in the result.
5. Align licensing with the go-ipfs project (MIT+Apache2).

[willscott]

Nice! This seems like a pretty clean interface

[warpfork]

Should (both of) the result channels be expected to be closed when this request is done?

Will the error channel be able to yield more than one error? Can FetchResult and errors be yielded intermingled?

Would this perhaps be clearer if this was unified into one channel, and FetchResult just contained either a Result or an error?

[acruikshank]

You're last comment is correct. I gave to 2 channels a go, but I think it's just too complicated to explain the behavior and properly process the results. I've changed it to a single channel with an error in the result.

[acruikshank]

Strike that. @hannahhoward pointed out ipfs/interface-go-ipfs-core#62. The reasoning here makes sense, so I'm keeping the error channel, modifying it so that it's always buffered and closed on completion and then documenting the behavior in the interface.