[grpc, utils] Size the HTTP/2 flow control windows (#841)

Type of change

Improvement (improvement to code, performance, etc)
New feature
Test update

Description

Adds connection.FlowControlConfig (flow-control: initial-window-size, initial-conn-window-size) to ClientConfig, MultiClientConfig, serve.ServerConfig and ordererdial.Config, and applies it to every gRPC dial and server, including orderer delivery and broadcast through deliverorderer.Parameters and ordererdial.Parameters.
Defaults the windows to 16 MB per stream and 32 MB per connection through default tags; zero leaves gRPC’s own BDP-based tuning in place.
The load generator picks its adapter by a field each client section needs, not by the section being present.
Documents the keys, commented out with their defaults, in the configuration samples, and the knob in docs/performance-tuning.md.

Additional details (Optional)

Adds BenchmarkSignatureVerifierManager to signature_verifier_manager_test.go, which drives the verifier manager’s sender over a real stream.
Widens utils/test helpers from *testing.T to testing.TB so the benchmark can share them.
A test checks that a loadgen config naming no adapter is rejected.

resolves #790

Signed-off-by: Liran Funaro liran.funaro@gmail.com

Background

The lifecycle of a transaction consists of 3 main stages:

Execution: First the transaction is sent to an endorser that will execute the transaction based on its current view of the ledger (this view may be stale). Then the endorser signs the transaction and forwards it to the next stage.

Ordering: The orderer will receive in parallel the signed transactions from the endorsers and will send them in a specific order to the next stage.

Validation: It takes place at the committer and it checks whether:

the signature is valid (not corrupt and it belongs to the endorsers)
the tokens (inputs or Serial Numbers/SN) have not already spent in a previous transaction (using the order as defined by the orderer)

Fabric-X Committer

Setup and Testing

See setup for details on prerequisites and quick start guide.

Execution: First the transaction is sent to an endorser that will execute the transaction based on its current view of the ledger (this view may be stale). Then the endorser signs the transaction and forwards it to the next stage.
Ordering: The orderer will receive in parallel the signed transactions from the endorsers and will send them in a specific order to the next stage.
Validation: It takes place at the committer and it checks whether:
- the signature is valid (not corrupt and it belongs to the endorsers)
- the tokens (inputs or Serial Numbers/SN) have not already spent in a previous transaction (using the order as defined by the orderer)