multiline: remove incorrect flush

[Syn3rman]

we are flushing the stream buffer in case it is
different in two consecutive runs, which leads to
incorrect parsing of multiline logs where we have
messages from different streams (stderr & stdout for ex) interleaved

#4387

Enter [N/A] in the box, if an item is not applicable to your change.

Testing
Before we can approve your change; please submit the following in a comment:

• Example configuration file for the change

[INPUT]
  Name tail
  Path ../cri.log
  Multiline.Parser cri
  Read_from_head True

[OUTPUT]
  name stdout
  match *

cri.log:

2021-11-18T14:47:34.730908438+00:00 stdout P start B
2021-11-18T14:47:34.730908438+00:00 stdout F end B
2021-11-18T14:47:34.730939216+00:00 stdout P C 1
2021-11-18T14:47:34.735454549+00:00 stderr F some log message D in stderr part one
2021-11-18T14:47:34.735482854+00:00 stdout F message C still continued after a line from a different stream

• Debug log output from testing the change

• Attached Valgrind output that shows no leaks or memory corruption was found

Fluent Bit v2.1.3
* Copyright (C) 2015-2022 The Fluent Bit Authors
* Fluent Bit is a CNCF sub-project under the umbrella of Fluentd
* https://fluentbit.io

[2023/05/24 12:30:33] [ info] [fluent bit] version=2.1.3, commit=5559192d2c, pid=22318
[2023/05/24 12:30:33] [ info] [storage] ver=1.4.0, type=memory, sync=normal, checksum=off, max_chunks_up=128
[2023/05/24 12:30:33] [ info] [cmetrics] version=0.6.1
[2023/05/24 12:30:33] [ info] [output:stdout:stdout.0] worker #0 started
[2023/05/24 12:30:33] [ info] [ctraces ] version=0.3.1
[2023/05/24 12:30:33] [ info] [input:tail:tail.0] initializing
[2023/05/24 12:30:33] [ info] [input:tail:tail.0] storage_strategy='memory' (memory only)
[2023/05/24 12:30:33] [ info] [input:tail:tail.0] multiline core started
[2023/05/24 12:30:33] [ info] [sp] stream processor started
[2023/05/24 12:30:33] [ info] [input:tail:tail.0] inotify_fs_add(): inode=271312 watch_fd=1 name=../cri.log
[0] tail.0: [[1637246854.730908438, {}], {"time"=>"2021-11-18T14:47:34.730908438+00:00", "stream"=>"stdout", "_p"=>"P", "log"=>"start Bend B"}]
[1] tail.0: [[1637246854.735454549, {}], {"time"=>"2021-11-18T14:47:34.735454549+00:00", "stream"=>"stderr", "_p"=>"F", "log"=>"some log message D in stderr part one"}]
[2] tail.0: [[1637246854.730939216, {}], {"time"=>"2021-11-18T14:47:34.730939216+00:00", "stream"=>"stdout", "_p"=>"P", "log"=>"C 1message C still continued after a line from a different stream"}]
^C[2023/05/24 12:30:35] [engine] caught signal (SIGINT)
[2023/05/24 12:30:35] [ warn] [engine] service will shutdown in max 5 seconds
[2023/05/24 12:30:35] [ info] [input] pausing tail.0
[2023/05/24 12:30:35] [ info] [engine] service has stopped (0 pending tasks)
[2023/05/24 12:30:35] [ info] [input] pausing tail.0
[2023/05/24 12:30:35] [ info] [output:stdout:stdout.0] thread worker #0 stopping...
[2023/05/24 12:30:35] [ info] [input:tail:tail.0] inotify_fs_remove(): inode=271312 watch_fd=1
[2023/05/24 12:30:35] [ info] [output:stdout:stdout.0] thread worker #0 stopped
==22318==
==22318== HEAP SUMMARY:
==22318==     in use at exit: 0 bytes in 0 blocks
==22318==   total heap usage: 1,771 allocs, 1,771 frees, 1,136,978 bytes allocated
==22318==
==22318== All heap blocks were freed -- no leaks are possible
==22318==
==22318== For lists of detected and suppressed errors, rerun with: -s
==22318== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

If this is a change to packaging of containers or native binaries then please confirm it works for all targets.

• Run local packaging test showing all targets (including any new ones) build.
• Set ok-package-test label to test for all targets (requires maintainer to do).

Documentation

• Documentation required for this feature

Backporting

• Backport to latest stable release.

---

Fluent Bit is licensed under Apache 2.0, by submitting this pull request I understand that this code will be released under the terms of that license.

[leonardo-albertovich]

It makes sense to me but the multiline tests are failing and we need to address that before we can proceed.

Once we understand why are those tests failing (did they expect this behavior? why?) we can provide a test build to the users as a second stage to validate the new behavior and then we can merge it.

[Syn3rman]

closing in favor of #7471