perf_reader: perf_reader_event_read will consume more than a one ring buffer worth of data

[JamesMBartlett]

PR copied from PR to iovisor/bcc
I noticed that in a single call to perf_reader_event_read, the perf_reader can end up reading more than a full ring buffer's worth of data. As long as the consumer side (perf_reader_raw_cb) is slower than the producer side (ebpf events from the kernel), then the ring buffer will fill up and the ring buffer's head position will always be behind its tail. Since the consumer is slower than the producer, as soon as the perf_reader updates the ring buffer tail position, the kernel will quickly write a new event and increment head. Because the perf_reader_event_read loop, reloads the ring buffer's head position on each iteration, its possible for this function to loop forever. This change just makes it so that the head position is read once at the start of the loop, and then the loop reads all the data up until this initial head position. The downside of this is that if data is written by the kernel during the perf_reader_event_read call it won't be read until the next call to perf_reader_event_read, but this seems acceptable to me compared to unbounded runtime of perf_reader_event_read.

I also added a test that demonstrates the behaviour above. The test has a thread that constantly writes to /dev/null, and then on the main thread it deploys a ebpf program that pushes 32kB of data to the ring buffer on every single write call. It also has a sleep in the callback function for the probe, that forces the consumer to be much slower than the producer. Then in a separate thread it calls perf_buffer->poll(0) and records how much data is received by the callback. Without the changes in this diff, this test would show that more than a full ring buffer's worth of data (times the number of perf_readers' the poll call touched) was received by the callback. I wasn't sure what kernel version perf buffer's are supported from, but based on test_perf_event.cc I assumed that 4.13 should be good. (Happy to remove the test from this diff if its not something you want, but thought it was useful to demonstrate the behaviour I'm trying to fix)

Looked for a style guide, but couldn't find one, so let me know if there are style issues.

cc. @oazizi000