rationale to clear queue during tcp_client_endpoint restart()

[joeyoravec]

What is the rationale for tcp_client_endpoint to clear the queue during restart()? See:

vsomeip/implementation/endpoints/src/tcp_client_endpoint_impl.cpp

Lines 102 to 128 in cf49723

	{
	std::lock_guard<std::recursive_mutex> its_lock(self->mutex_);
	for (const auto &q : self->queue_) {
	const service_t its_service = VSOMEIP_BYTES_TO_WORD(
	(*q.first)[VSOMEIP_SERVICE_POS_MIN],
	(*q.first)[VSOMEIP_SERVICE_POS_MAX]);
	const method_t its_method = VSOMEIP_BYTES_TO_WORD(
	(*q.first)[VSOMEIP_METHOD_POS_MIN],
	(*q.first)[VSOMEIP_METHOD_POS_MAX]);
	const client_t its_client = VSOMEIP_BYTES_TO_WORD(
	(*q.first)[VSOMEIP_CLIENT_POS_MIN],
	(*q.first)[VSOMEIP_CLIENT_POS_MAX]);
	const session_t its_session = VSOMEIP_BYTES_TO_WORD(
	(*q.first)[VSOMEIP_SESSION_POS_MIN],
	(*q.first)[VSOMEIP_SESSION_POS_MAX]);
	VSOMEIP_WARNING << "tce::restart: dropping message: "
	<< "remote:" << self->get_address_port_remote() << " ("
	<< std::hex << std::setfill('0')
	<< std::setw(4) << its_client << "): ["
	<< std::setw(4) << its_service << "."
	<< std::setw(4) << its_method << "."
	<< std::setw(4) << its_session << "]"
	<< " size: " << std::dec << q.first->size();
	}
	self->queue_.clear();
	self->queue_size_ = 0;
	}

Let's say the the train is loaded with several passengers and the TCP socket gets broken-then-reopened. This tends to happen around startup or suspend-to-ram while the system is unstable. In this case:

• if we let the passengers stay on the train they might transmit milliseconds later, as soon as the socket gets re-established
• it's not clear that clearing all passengers will "fix" anything causing a TCP socket break. If anything [BUG]: tcp_client_endpoint must unset is_sending_ during restart #668 actually introduced a bug by clearing the train
• emptying the train and all passengers might help to make REMOTE_ERROR more atomic; might guarantee that no passenger goes out after a client was informed of failure? it would be weird if an event transmitted hours later

It seems like an architectural tradeoff between "riding out" brief interruptions in network connectivity and returning error codes more often to clients. Why was this selected?