Consumer: strip ring buffer header when consuming ctf2 ring buffer packet

Consumer: strip ring buffer header when consuming ctf2 ring buffer packet

On the kernel tracer side, providing a header free packet would be quite
intrusive in term of ABI/API modification. Thus for now, the kernel
tracers keeps the notion of header. On the consumer side, we can drop
the header as necessary based on the format we expect or we could even
inspect the header if necessary. For now, we chose to trust the
configured format for the session since we have access to the
information.

On the userspace side, historically the usage of a "ring buffer" for the
metadata was somewhat driven by the ctf1 "requirement" of providing
header for a given metadata packet. Essentially in ctf1 the ring buffer
packet "metadata" leaks into the actual ctf1 spec. It also happened that
the same machinery could then be reused for both the kernelspace and
userspace metadata ingestions.

CTF2 drop all this so could lttng-tools! But, considering that ctf1
still need to be supported for a while and that we still need to have
all the machinery for consuming from the kernelspace metadata
ringbuffer, keeping the current data path for both userspace and
kernelspace for metadata is probably a safer bet.

The only "drawback" here is that headers for the userspace metadata
ringbuffer contain version fields that will be equivalent to 1.8 despite
the fact that it contains ctf2 metadata. This is because the version is
currently hard coded by lttng-ust into the metadata packet headers.

Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Change-Id: I761c8a7d9742cbc9c875767233f2d30a43b9743f