misuse of state history's get_blocks_ack_request_v0 can lead to "stuck" state history connection

[spoonincode]

eos-evm-node's state history request sets max_messages_in_flight to 4096,

eos-evm-node/src/ship_receiver_plugin.cpp

Lines 117 to 121 in 3a1eaaa

	auto send_get_blocks_request(uint32_t start) {
	eosio::ship_protocol::request req = eosio::ship_protocol::get_blocks_request_v0{
	.start_block_num = start,
	.end_block_num = std::numeric_limits<uint32_t>::max(),
	.max_messages_in_flight = 4*1024,

But when it sends get_blocks_ack_request_v0 it seems to send the total number of messages it has received so far (I don't see num_messages reset to 0, except on connection failure),

eos-evm-node/src/ship_receiver_plugin.cpp

Lines 348 to 350 in 3a1eaaa

	if(++num_messages % 1024 == 0) {
	//SILK_INFO << "Block #" << block->block_num;
	auto ec = send_get_blocks_ack_request(num_messages);

This is not proper use of the get_blocks_ack_request_v0 interface. max_messages_in_flight+get_blocks_ack_request_v0 is a simple credit system where on the initial request the number of credits are established, nodeos decreases its credit count on each block it sends, and get_blocks_ack_request_v0 credits back the given number.

If I did the math right, after about 3 million blocks the current code will roll over nodeos' credit counter. When this occurs nodeos might think it has 0 credits and stop sending blocks.

For a c++ reader not sure it's worth bothering with non-UINT32_MAX max_messages_in_flight since socket back pressure works properly. The primary reason this exists as part of the ship protocol is that websockets in nodejs lacked (lacks?) proper socket back pressure. So IMO should just set max_messages_in_flight = UINT32_MAX and get rid of the ack stuff.

[stephenpdeos]

Aligned on approach to set max_messages_in_flight = UINT32_MAX and get rid of the ack stuff