increase TNS state downloading timeout to 120 seconds

[tersec]

Over time, the natural ratio of largeRequestsTimeout to smallRequestsTimeout should increase, since the states (which contain both active and inactive validators) grow faster than the ongoing network traffic (which contain only active validators).

Reported the other day in #dev-helpdesk in Discord:

[github-actions]

Unit Test Results

         9 files  ±0    1 334 suites  ±0   29m 27s ⏱️ -40s
  5 064 tests ±0    4 716 ✔️ ±0  348 💤 ±0  0 ❌ ±0 
20 991 runs  ±0  20 587 ✔️ ±0  404 💤 ±0  0 ❌ ±0 

Results for commit 66a296c. ± Comparison against base commit f258cba.

[cmd0s]

In my opinion, the current hardcoded timeout of 120 seconds is still insufficient for many scenarios. Slower networks, such as those with 16 Mbps download speeds, frequently fail to complete synchronization within this limit. Instead of advocating for yet another fixed increase to the timeout value, I propose a flexible solution: this Pull Request introduces a configurable --large-requests-timeout parameter for nimbus_beacon_node in trustedNodeSync mode.

Pull Request --> #6781

This approach empowers users to adapt the timeout to their network conditions, ensuring successful synchronization without altering the code. The default value remains at 120 seconds, maintaining backward compatibility, but users with challenging network conditions can now specify a custom timeout, such as --large-requests-timeout=300.

I lead the Web3Pi.io project, empowering users to seamlessly and automatically set up a full Ethereum node on Raspberry Pi devices. This streamlined setup includes both execution and consensus clients, with Nimbus as the default consensus client.

Our users span various countries and have diverse network conditions, ranging from high-speed connections to more constrained ones. For some users with slower connections, completing trustedNodeSync has been challenging. After examining this issue, I found that the timeout value for largeRequestsTimeout can be a limiting factor in certain cases. While increasing this value resolves the issue, I wanted to propose a more flexible and user-friendly approach to accommodate a wider range of network scenarios.

I believe this solution not only addresses the immediate synchronization issues but also enhances the versatility of nimbus_beacon_node for diverse environments. Thank you for considering this Pull Request!