BUG/MEDIUM: log/ring: broken syslog octet counting

As reported by Tristan in GH haproxy#2561, syslog messages sent over rings are
malformed since commit 01aa0a0 ("MEDIUM: ring: change the ring reader
to use the new vector-based API now").

Indeed, take a look at the following log message produced prior to
01aa0a0:

  181 <134>1 2024-05-07T09:45:21.543263+02:00 - haproxy 113700 - - 127.0.0.1:56136 [07/May/2024:09:45:21.491] front front/s1 0/0/21/30/51 404 369 - - ---- 1/1/0/0/0 0/0   "GET / HTTP/1.1"

Starting with 01aa0a0, here's the equivalent log message:

  <134>1 2024-05-07T09:45:21.543263+02:00 - haproxy 112729 - - 127.0.0.1:56136 [07/May/2024:09:45:21.491] front front/s1 0/0/66/39/105 404 369 - - ---- 1/1/0/0/0 0/0   "GET / HTTP/1.1"-fwr

-> Message is missing octet counting header, and garbage bytes are found
at the end of the payload.

This bug is caused by a small mistake in syslog_applet_append_event():
when the function was refactored to use vector API instead of buffer
API, we used 'trash.area' as starting pointer to write the event instead
of 'trash.area + trash.data', causing existing octet counting prefix
(already written in trash) to be overwritten and trash.data to be
wrongly incremented.

No backport needed (01aa0a0 was introduced during 3.0 development)

Author: Darlelet

src/log.c

@@ -5517,7 +5517,7 @@ ssize_t syslog_applet_append_event(void *ctx, struct ist v1, struct ist v2, size
 		return -2;
 
 	/* try to transfer it or report full */
-	trash.data += vp_peek_ofs(v1, v2, ofs, trash.area, len);
+	trash.data += vp_peek_ofs(v1, v2, ofs, trash.area + trash.data, len);
 	if (applet_putchk(appctx, &trash) == -1)
 		return -1;