rs_fatal is overused

[sourcefrog]

librsync has a function/macro rs_fatal etc, to indicate severe errors or internal bugs, which calls abort().

However as a well-behaved library, it's probably better if it doesn't do that unless there's no safe way to cleanly unwind. Probably most uses should be pulled out and it should just return an error.

[sourcefrog]

Actually it turns out it was accidentally not fatal on non-gcc compilers, but this should be fixed by 18af8d0.

[dbaarda]

My thoughts on this are;

anything that is a programming error (violating "contract" pre/post/invariant conditions), such as calling a function with invalid arguments or corrupted data-structures, should be checked with assert statements. These should never happen for valid code, so we don't want to waste cpu cycles on them in a production release, but we want to catch them in debug builds.

Anything that is very rare and basically unrecoverable for the whole program, like malloc failures, should be rs_fatal.

Anything that is an error caused by external things beyond the program's control, like bad input data, or that break librsync in ways that shouldn't kill the whole program, should be caught and return an error code for the program to handle as it sees fit.

Note I fixed quite a few of these in pull #88. A quick search shows not many left that are not meeting the criteria above. The only ones left that need changing are things that are checking programming errors and thus could be replaced with asserts for efficiency. This means we don't call rs_fatal() in any places that would be considered "not well-behaved library behaviour" any more.