[FEATURE] Support large message sizes with end-of-FIXS message marker in TCP/IP

[yunlishao]

Is your feature request related to a problem?
Currently, the TCP/IP communication in RS_FIXS may have limitations handling large messages. Without a proper end-of-message delimiter or marker, it's difficult to reliably transmit and receive variable-length messages, especially when dealing with large vehicle data sets or complex traffic scenarios that exceed typical buffer sizes.

Describe the solution you'd like
Implement support for large message sizes in the TCP/IP communication layer with a well-defined end-of-FIXS message marker/delimiter. This would include:

1. Define a unique end-of-message marker (e.g., a specific byte sequence like \r\n\r\n, \xFF\xFF\xFF\xFF, or a custom delimiter)
2. Update the SocketHelper class to handle message framing with this delimiter
3. Implement proper buffering to accumulate partial messages until the delimiter is received
4. Handle edge cases where the delimiter might be split across multiple TCP packets
5. Add support for messages larger than the current buffer size by dynamically growing buffers or using chunked reads
6. Ensure backward compatibility with existing message formats

Describe alternatives you've considered

• Length-prefix approach: Prepend each message with a fixed-size header containing the message length. This requires knowing the full message size upfront.
• Fixed-size messages: Pad all messages to a maximum size, which is wasteful for smaller messages.
• Custom binary protocol: Implement a more complex protocol with message types, lengths, and checksums, though this adds significant complexity.
• Using existing serialization libraries: Adopt Protocol Buffers, MessagePack, or similar, though this would require larger refactoring.

Environment (if feature is environment-specific)

• Python version: N/A
• C++ compiler/version: (relevant for SocketHelper implementation)
• MATLAB/Simulink/dSPACE version: N/A
• CARLA version: N/A
• SUMO version: (impacts message sizes)
• VISSIM version: (impacts message sizes)
• IPG Carmaker version: N/A

Additional context
Looking at TrafficHelper.cpp, the system handles vehicle data through SocketHelper when using VISSIM mode. Large scenarios with many vehicles or extensive subscription data could exceed current buffer limits.

Key files to modify:

• CommonLib/SocketHelper.cpp / CommonLib/SocketHelper.h - Core TCP/IP communication
• CommonLib/MsgHelper.cpp / CommonLib/MsgHelper.h - Message packing/unpacking
• CommonLib/TrafficHelper.cpp - Integration with traffic simulators

Example pseudocode for the delimiter approach:
```cpp
const std::string END_OF_MESSAGE = "\r\n\r\n";

// Sending side
void sendMessage(int socket, const std::string& message) {
std::string messageWithDelimiter = message + END_OF_MESSAGE;
send(socket, messageWithDelimiter.c_str(), messageWithDelimiter.size(), 0);
}

// Receiving side
std::string receiveMessage(int socket) {
std::string buffer;
char chunk[1024];
while (true) {
int bytesRead = recv(socket, chunk, sizeof(chunk), 0);
buffer.append(chunk, bytesRead);

    size_t delimiterPos = buffer.find(END_OF_MESSAGE);
    if (delimiterPos != std::string::npos) {
        std::string message = buffer.substr(0, delimiterPos);
        // Keep remaining data for next message
        buffer = buffer.substr(delimiterPos + END_OF_MESSAGE.length());
        return message;
    }
}

}
```

This enhancement would improve robustness and scalability of the RS_FIXS communication layer.