OOB access with huge buffers (src/lib/buf/buffers.c)

Here is an out-of-bounds read bug found by paldium in hackerone. It's a low-severity bug because it can only be used for DoS, and requires transfer of more than INT_MAX bytes through a connection.

We should backport to 029 and forward anyhow.

# Summary
It is possible to trigger out of boundary accesses with buffers if their content exceeds INT_MAX bytes. See my first patch (0001) how to trigger the issue through unit tests, as this is the easiest way to see what happens. It will result in an out of boundary read. A 64 bit system with at least 5 GB is required for this unit test though!

# Explanation
A buffer consists of one or multiple chunks, which actually contain the data. A chunk contains a memory region and a data pointer. The data pointer points somewhere into the memory, where the actual user data is stored.

Even though a chunk is free to be larger than INT_MAX, it cannot be advised to use such chunks. Whenever a function performs searches or lookups, it is bound to "int" due to buf_pos_t. Many functions properly check that INT_MAX is not exceeded and throw assertions, but unfortunately not all...

Keeping that in mind, I was able to perform a sequence of actions that in fact create chunks with a data length greater than INT_MAX. The int variable "pos" will eventually overflow and access memory far ahead from reserved user data, effectively performing an out of boundary access.

# Exploitation
Generally this is a defensive coding measure to make sure that buffers are safe.

It should be possible to trigger a huge buffer in src/core/mainloop/connection.c. In function connection_buf_read_from_socket a linked connection (directory authentication, as far as I can tell) is joined into the connection buffer with buf_move_to_buf.

The return value of buf_move_to_buf is not properly checked, which means that excessively large data returned from the linked connection can slowly increase the value of "max_to_read" which means that more and more data can be stored in the connection. 

Should it eventually overflow INT_MAX (granted, this takes a LOOONG time), the integer calculation will corrupt the buffer, leading to out of boundary operations.

# Patch
To prevent this issue, both patches (0002 to fix buffers and 0003 to check for error return value) must be applied.

## Impact

Heap data is corrupted and out of boundary read access occur. It will be very hard to extract data with that, because it would be a blind memory check -- and will most likely directly cause a segmentation fault.

Most likely attack vector is therefore denial of service.