api: Add bzz-feed-raw scheme to retrieve arbitary feed update

[nolash]

This PR adds an HTTP scheme bzz-feed-raw the enables direct retrieval of the raw chunk contents from a reference. The use case that prompted the change was the desire tocircumvent the lookup algorithm of feeds to access only a particular update if it exists, without having to wait for the additional lookups the algorithms execute to finish (and fail if there are no newer ones)

[acud]

This is not tested at all

[nolash]

fair enough

[janos]

It looks to me that only comments on exported functions are missing. Otherwise LGTM.

[acud]

Semantically I'm not sure why raw was appended to feed, as I'm not sure that its rawness differs in any way from bzz-feed at all (both return an octet stream mime type). So I find the naming confusing.

Personally I think we're better off adding this functionality into the normal Feed handler and just toggle it with a querystring param, even more so since feeds already have tweakable options through querystrings - do we really need to introduce a new scheme just in order to facilitate one type of request? I'm not sure I see the benefit.

[nolash]

@acud I think the relation between the data accessed by bzz-feed: and bzz-feed-raw: is much the same as between bzz: and bzz-raw:.

bzz-feed: manipulates and accesses feeds via a pointer, whereas the data is actually stored in a different chunk. With bzz: this pointer comes in the form of a manifest, which in turn directs you to the actual data to fetch.

Furthermore, bzz-feed: conceals a time-series scheme to access feeds. bzz-feed-raw: omits this completely, so thus the two schemes don't even provide the same functionality.

Lastly, I'm not very happy with the use of query string parameters in the bzz-feed interface as it is - at least not the POST part. I would have liked to see multipart body or use of headers instead. But we don't currently have this, and I would like to add this functionality for now without having to refactor all of it.