Enumerate collection response :bodys via reduce.

[llasram]

In Clojure 1.5+, the CollReduce protocol provides a more flexible definition of a "collection" than ISeq. In particular in the context of generating streaming chunked-encoded HTTP responses, CollReduce implementations may have lexically-scoped finally-style resource clean-up code.

Modiying the ring servlet adapter to use CollReduce instead of ISeq when available, then process the body via reduce instead of doseq should provide these benefits in an entirely backwards-compatible fashion.

This PR somewhat orthogonally fixes what I believe to be a bug in the current support for ISeq bodies. Apparently PrintWriter instances never throw exceptions after construction, so e.g. a client closing a connection before completely recieving a chunked-encoded response would leave the doseq continuing to iterate until it had exhausted the body seq. The .checkError method acts a .flush, but also reports if an error has occurred, allowing the adapter to throw an exception.

[weavejester]

This seems a reasonable change. It'll require additional tests, however.

The SPEC should be written with CollReduce as an additional option, not as ISeq|CollReduce.

[llasram]

Force-pushed an updated PR. I added a test covering String, ISeq, and CollReduce bodies. Extending that to InputStream would require dealing with proxying ServletOutputStream, so I've left that as a future exercise, but it remains no less tested than before.

[weavejester]

@mmcgrana do you want to take a look at this? It extends the SPEC in a small way.

[weavejester]

This looks fine to me, btw.

[mmcgrana]

Looks reasonable to me.

[weavejester]

I've been working on an update to the Ring lint middleware, and I've come across an issue that may mean I'll need to revert these changes.

The CollReduce protocol in Clojure 1.5+ applies to all objects, whether they are truly reducible or not. This means that just checking whether an object satisfies the CollReduce protocol is not sufficient to determine whether the object is actually reducible or not.

@mmcgrana, @llasram - my thought is to pull this from the upcoming release, and instead consider a Ring-specific protocol that will provide finer control over how response bodies are outputted.