#8293 fix concurrent access to PQ persisted bytesize throwing

[original-brownbear]

See error reported in #8293, obviously looping over the tail pages will throw on concurrent modification of the underlying ArrayList.
Unfortunately, the stack trace of that error doesn't get forwarded to Ruby and also seems to prevent the mutex covering the PQ data poll on the Ruby side from unlocking (that's a different issue imo, no clue why this is happening).
=> Either way, fixed by locking that operation in PQ and preventing concurrent modification exceptions.

• I'm aware that this needs a stronger fix, in the long run, it's not ok having to lock the pipeline for this, but for the current implementation, I see no other fix that doesn't add the same degree of locking.

[jordansissel]

Most tests passing. Only 1 DLQ test failing and is unrelated.

LGTM

[suyograo]

@original-brownbear can we backport this to 5.6 as well?

[original-brownbear]

@suyograo sure, let's see this might even merge clean :)

[elasticsearch-bot]

Armin Braun merged this into the following branches!

Branch	Commits
master	ffb72d3
6.x	fc1b548

[elasticsearch-bot]

Armin Braun merged this into the following branches!

Branch	Commits
6.0	cacaa62

[elasticsearch-bot]

Armin Braun merged this into the following branches!

Branch	Commits
5.6	64dacdd

[original-brownbear]

@suyograo done :)

[colinsurprenant]

Just helped diagnose an issue on discuss which pointed to this rather obvious lack of locking and found this fix - thanks @original-brownbear this one was pretty nasty, good thing we also merged it in 5.6.