Resource streams improved: Filter chain hooks, byte range support

[jccr]

This allows for support of:

• Obfuscated fonts (HTTP byte range request is fulfilled with binary response of whole remaining stream? SDKLauncher-Android#44)
• HTTP range requests (Support for obfuscated fonts SDKLauncher-Android#29)

This fixes the following issues:
#132 - Reading filter chain aware byte streams should be more clear now (PackageResource helper class)
#103 - This is fixed for non filter chain byte streams (now called raw input streams)

Potentially fixes readium/SDKLauncher-Android#22

[danielweck]

Just to highlight a fundamental difference between the Android and iOS / OSX launchers (at this stage of ), which we may need to take into consideration when looking into LCP or other DRM encryption schemes.

Right now, the NanoHTTP server pulls binary data from the response's input stream into 16kB buffers:
https://github.com/readium/SDKLauncher-Android/blob/develop/SDKLauncher-Android/src/fi/iki/elonen/NanoHTTPD.java#L622

int BUFFER_SIZE = 16 * 1024;
byte[] buff = new byte[BUFFER_SIZE];
while (pending > 0) {
    int read = data.read(buff, 0, ((pending > BUFFER_SIZE) ? BUFFER_SIZE : pending));
    if (read <= 0) {
        break;
    }
    outputStream.write(buff, 0, read);

    pending -= read;
}

In iOS and OSX, CocoaHTTPServer also feeds HTTP response bytes into its underlying socket (using 256kB or 512kB buffers, depending on the platform), however this is directly correlated to the size of data chunks that incrementally pass through a non-cached Content Filter (filterData() method). For example, an encrypted image file is typically not requested by WebView via HTTP byte-range (just a regular HTTP request), but the actual byte packets would still be fragmented into distinct consecutive chunks (thus why a decryption algorithm must track its state (previous blocks, etc.)).
I see that in the current Android implementation, this correlation is non-existent, because the input stream is initialised with an intermediary pre-fetched byte buffer that represents the full resource:
https://github.com/readium/SDKLauncher-Android/blob/feature/obfuscatedFonts/SDKLauncher-Android/src/org/readium/sdk/android/launcher/util/EpubServer.java#L182

byte[] data = packageResource.readDataFull();
res = new Response(Response.Status.OK, mime, new ByteArrayInputStream(data));

Note that even an HTTP byte-range request fetches the full queried data before passing it into a stream:
https://github.com/readium/SDKLauncher-Android/blob/feature/obfuscatedFonts/SDKLauncher-Android/src/org/readium/sdk/android/launcher/util/EpubServer.java#L177

 byte[] data = packageResource.readDataOfLength((int) newLen, (int) startFrom);
res = new Response(Response.Status.PARTIAL_CONTENT, mime, new ByteArrayInputStream(data));

Behind the scenes, the ResourceStream is indeed initialised with BUFFER_SIZE, which informs the rate of transfer from the underlying Readium SDK byte stream (which could potentially be bound to a Content Filter filterData()):
https://github.com/readium/readium-sdk/blob/feature/AndroidByteRangeStream/Platform/Android/jni/resource_stream.cpp#L133

std::size_t bytesRead = byteStream->ReadBytes(&tmpBuffer, readLength);

(see readLength = stream-> getBufferSize())

To conclude, this design is totally fine for now. In a future iteration, we might want (or not) to consider an alternative to the aforementioned ByteArrayInputStream, for example a "real" stream that would pull data incrementally from the underlying Readium SDK byte stream, thereby avoiding the intermediary byte[] full/range buffer prefetching, and correlating more directly with the 16kB buffer that the HTTP server uses. At any rate, I feel that the 4kB buffer is a bit small, and may be suboptimal with some encryption schemes.