Add some initial binary queue samples

[andrewvc]

Tests for old binary queues. Currently only tests 6.3.0.

I think this is ready for review. I think I should remove all the examples from before 6.3.0 since we know they are all problematic. However, I want to get a second opinion before I throw them away. Thoughts?

[andrewvc]

@original-brownbear @danhermann thoughts on this?

[danhermann]

Ideally, these samples would include an exhaustive set of types that can be serialized. It would also be nice if the test could verify that all possible types were present in a particular sample by checking against the list of available converters here:

https://github.com/elastic/logstash/blob/master/logstash-core/src/main/java/org/logstash/Valuefier.java#L100-L155

That's still a little tricky since there's a fall-through converter that attempts to convert based on the assignability of a class to anything in the above list. I don't know if these test criteria are overly ambitious for right now, but it's definitely something I intend to do for PQv2.

[danhermann]

Minor -- I prefer putting code that's used only in tests somewhere in the test source tree.

[original-brownbear]

+1

[andrewvc]

+1

[original-brownbear]

@andrewvc @danhermann as far as I can see we have all the types in here with the exception of BigDecimal don't we?
I like this one I think :)

[danhermann]

What about nil, symbols, floats? And I like the test, too. I just think it would be ideal if the test itself verified that it was testing all possible types though, as I said, that may not be necessary at this point.

[original-brownbear]

Right and those :)

[andrewvc]

@danhermann @original-brownbear thanks for the feedback.

I'll incorporate it. I should have had the config reviewed before generating samples.

[original-brownbear]

@andrewvc np. Actually, before you waste your time regenerating all the samples one thought:

Do we even need to generate anything but data for 6.2.4 and 6.3.x+? There's so many known compatibility issues there and we decided not to write a transcoder as far as I understand. Why even test these cases, they'll always be broken?

[andrewvc]

@original-brownbear good point, let's just generate 6.3.0, we don't even promise 6.2.4 compat.

[mergify]

This pull request does not have a backport label. Could you fix it @andrewvc? 🙏
To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

• backport-8./d is the label to automatically backport to the 8./d branch. /d is the digit.
• backport-8.x is the label to automatically backport to the 8.x branch.

[mergify]

backport-8.x has been added to help with the transition to the new branch 8.x.
If you don't need it please use backport-skip label.