ARROW-1629: [C++] Add miscellaneous DCHECKs and minor changes based on infer tool output

[wesm]

This was an interesting journey through some esoterica. I went through all the warnings/errors that infer (fbinfer.com) outputs and made changes if it seemed warranted. Some of the checks might be overkill.

See https://gist.github.com/wesm/fc6809e4f4aaef3ecfeb21b8123627bc for a summary of actions on each warning

Most of the errors that Infer wasn't happy about were already addressed by DCHECKs. This was useful to go through all these cases -- in nearly all cases the null references are impossible or would be the result of an error on behalf of the application programmer. For example: we do not do array boundschecking in most cases in production builds, but these boundschecks are included in debug builds to assist with catching bugs caused by improper use by application developers.

As a matter of convention, we should not use error Status to do parameter validation or asserting pre-conditions that are the responsibility of the library user. If parameter validation is required in binding code (e.g. Python), then this validation should happen in the binding layer, not in the core C++ library.

There are some other cases where we have a std::shared_ptr<T> out variable with code like:

RETURN_NOT_OK(Foo(..., &out));
out->Method(...);

Here, infer complains that out could contain a null pointer, but our contract with developers is that if Foo returns successfully that out is non-null.

Interestingly, infer doesn't like some stack variables that are bound in C++11 lambda expressions. I noted these in the gist with LAMBDA.

[pcmoritz]

+1 the plasma related changes look good to me! I'm very glad it caught the memory leak.

I'd like to do some modernizations on the Plasma code base, in particular getting rid of fling and using explicit MemoryMappedFile from https://github.com/apache/arrow/blob/84e5e02fbf412c979387b0a53b0ad0c6d5c5e790/cpp/src/arrow/io/file.h instead of shipping file descriptors between processes; this will make it harder to do the cleanups properly since we cannot rely on the reference counting from the OS any more to clean the files up after they are not used by anyone any more, but it will make it possible to have a native Java client and potentially other native bindings. I wonder what your thoughts on this tradeoff are.

[wesm]

+1