systest: add QUIC support

[ivan4th]

Motivation

QUIC protocol is not verified in systests

Description

This adds a job that runs systests using QUIC instead of TCP

Test Plan

Make sure systests pass in both modes

TODO

• Explain motivation or link existing issue(s)
• Test changes and document test plan

[ivan4th]

bors try

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 80.6%. Comparing base (63dc6a8) to head (d8024a1).
Report is 5 commits behind head on develop.

Additional details and impacted files

@@           Coverage Diff           @@
##           develop   #5902   +/-   ##
=======================================
  Coverage     80.6%   80.6%           
=======================================
  Files          286     285    -1     
  Lines        29508   29547   +39     
=======================================
+ Hits         23801   23833   +32     
- Misses        4116    4130   +14     
+ Partials      1591    1584    -7     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[spacemesh-bors]

try

Build failed:

• systest-status

[ivan4th]

bors try

[spacemesh-bors]

try

Build failed:

• systest-status

[ivan4th]

bors try

[spacemesh-bors]

try

Build failed:

• systest-status

[dshulyak]

it additionally runs all of the tests but with the quic enabled?
it will use twice as much resources on gke, might be just x2 cost with autoscaling.

it also seems very wastesful, as the change to run quic rather minor.
some other ideas, setup half of the nodes with quic, other with tcp, run one any test with all nodes using quic, add one more additional test specifically with quic e.g TestSmeshingQuic

[fasmat]

Regarding adding a TestSmeshingQuic test or adapting configuration of nodes for tests, I'd say the decision should be based on what we consider the "default" setup.

If both quic and tcp are considered equally supported by us we should just make half of all nodes in every test use quic and the other half tcp. If we consider quic experimental or a feature that only some nodes should enable I'd go with a TestSmeshingQuic test.

[fasmat]

Also running all our system tests twice will more than doubles the number of tries / merges that fail due to a flaky test failing and we should look into stabilizing our system tests first before adding a bunch of additional tests.