Don't restrict users to small puts

[stuarteberg]

Attempting to push moderately large label volumes results in an error:

Cannot allocate larger than INT_MAX

Where INT_MAX is 2^31. It isn't clear to me exactly why this restriction is necessary. Even if it is necessary, it would be nice to handle the necessary splitting/looping internally, so the client doesn't have to worry about it.

[stephenplaza]

I agree that we could technically handle the splitting and looping, but this interface (for the most part) tries to mirror DVID's interface. DVID has a restriction on how much you can POST at once. I think the restriction makes it very clear to users that they should reconsider their workflow if they need to do such a large monolithic POST.

That being said, perhaps an idiomatic thing would be to extend some of the 'algorithms' that libdvid provides. I added code a few weeks ago that handles gets and posts of arbitrarily large bodies (see DVIDThreadedFetch). In theory, this functionality could be inlined with the rest of the API but their complexity and time guarantees are much different than the rest of the API.

[stuarteberg]

DVID has a restriction on how much you can POST at once.

Thanks for the info -- I didn't know that. What is the limit?

[stephenplaza]

Not sure. I think it is around 1-2 GB. I should probably match that exactly in libdvid but I got lazy and just chose INT_MAX.