Fix: don't access packet header for stream_id and stream_instance_id getters

Fix: don't access packet header for stream_id and stream_instance_id getters

The stream ID and stream instance ID are invariant for a stream, so
there is no point reading them from the packet header currently owned by
the consumer (between get/put subbuf).

Actually, the consumer try to access the stream_id from the live timer
when sending a live beacon without getting the reader subbuffer first.
Doing so is racy against producers. In typical live scenarios
(non-overwrite channels), the producers will always write the same
stream id and stream instance id values at the same header offsets,
which will "work", except for the initial state of an empty buffer:
the value "0" will be returned (erroneously).

For the less frequently used scenario of a live session with "overwrite"
channels, this will trigger WARN_ON safety nets in libringbuffer. This
safety net triggers a kernel OOPS report and disables tracing for that
channel.

In the case where a ring buffer does not have any data ready, it makes
no sense to try to get a subbuffer for reading anyway, so the approach
was broken.

So return the stream id and stream instance id from the internal
data structures rather than reading it from the ring buffer.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>