[C++] Add test exhibiting recording descriptor bug in stored channel strings

[jrsala-auguration]

This is not a finished PR. This just adds a failing test that should pass.

The EXPECT_EQ(originalChannel, m_recordingChannel); assertion fails as follows:

AeronArchiveTest.cpp:1402: Failure
Expected equality of these values:
  originalChannel
    Which is: "aeron:udp?endpoint=localhost:3333\t"
  m_recordingChannel
    Which is: "aeron:udp?endpoint=localhost:3333"

There's always an extra byte at the end of the channel strings in recording descriptors, whether it's originalChannel or strippedChannel or sourceIdentity.

I don't know what the solution is. The generated SBE code seems correct. For good measure I added that same assertion to the jumbo recording descriptors test, which fails in the same way.

[jrsala-auguration]

Note that the CI checks for the various GCC and Clang versions succeed despite the test failing. The Windows check fails as it should. Maybe something is not right in the CI setup if test outcomes are ignored.

[tmontgomery]

My guess on this is that the RecordingDescriptorPoller is running off the end of the string due to not using the string version of the get field. i.e. getOriginalChannelAsString. The compiler might be making an explicit conversion from a const char * to a std::string which doesn't have a length, so the end of the string has the next field varDataEncoding.

[jrsala-auguration]

@tmontgomery Things I also tried that didn't work in ControlResponseAdapter.cpp, where m_onRecordingDescriptor is called:

descriptor.getOriginalChannelAsString(),

std::string(descriptor.originalChannel(), descriptor.originalChannelLength()),

I looked at the encoding side in Java class RecordingDescriptorEncoder and it seemed fine. It seems to be used correctly in Catalog#addNewRecording.

[tmontgomery]

No. It is actually as I mentioned. I've added your tests and my fix and seems fine. Will push once I run a cppbuild.

[tmontgomery]

commit is d95157f

[jrsala-auguration]

fixed