fix(e2e): Increase number of tries in bytes up down empty test

[moduli]

Description

This PR attempts to address flaky e2e test TestCliBytesUpDownEmpty. This applies a similar fix as #6401

│ === RUN   TestCliBytesUpDownEmpty
│     scope.go:91: Created Org Id: o_t8StP2oZ0S
│     scope.go:130: Created Project Id: p_eKfBFkPoQQ
│     target.go:182: Created Target: ttcp_VMGc7CIh09
│     session.go:32: Waiting for session to appear...
│     bytes_up_down_empty_test.go:55: Starting session...
│     session.go:57: Found 1 session(s)
│     session.go:64: Created Session: s_v2GwnFnnDx
│     bytes_up_down_empty_test.go:77: Waiting for bytes_up/bytes_down to be greater than 0...
│     bytes_up_down_empty_test.go:113: bytes_up: 0, bytes_down: 0, bytes_up or bytes_down is not greater than 0. Retrying...
│     bytes_up_down_empty_test.go:113: bytes_up: 0, bytes_down: 0, bytes_up or bytes_down is not greater than 0. Retrying...
│     bytes_up_down_empty_test.go:113: bytes_up: 0, bytes_down: 0, bytes_up or bytes_down is not greater than 0. Retrying...
│     bytes_up_down_empty_test.go:113: bytes_up: 0, bytes_down: 0, bytes_up or bytes_down is not greater than 0. Retrying...
│     bytes_up_down_empty_test.go:113: bytes_up: 0, bytes_down: 0, bytes_up or bytes_down is not greater than 0. Retrying...
│     bytes_up_down_empty_test.go:113: bytes_up: 0, bytes_down: 0, bytes_up or bytes_down is not greater than 0. Retrying...
│     bytes_up_down_empty_test.go:116: 
│         	Error Trace:	/src/boundary/testing/internal/e2e/tests/base/bytes_up_down_empty_test.go:116
│         	Error:      	Received unexpected error:
│         	            	bytes_up: 0, bytes_down: 0, bytes_up or bytes_down is not greater than 0
│         	Test:       	TestCliBytesUpDownEmpty
│ --- FAIL: TestCliBytesUpDownEmpty (37.44s)

The theory is that the fields for bytes_up and bytes_down can take some time to get updated. The test will now retry more times before considering it a failure.

https://hashicorp.atlassian.net/browse/ICU-18230\

PCI review checklist

• I have documented a clear reason for, and description of, the change I am making.
• If applicable, I've documented a plan to revert these changes if they require more than reverting the pull request.
• If applicable, I've documented the impact of any changes to security controls.
  Examples of changes to security controls include using new access control methods, adding or removing logging pipelines, etc.