- MaxInflightMsgs is internal to etcd/raft and should be exposed
to users with a more appropriate name: MaxInflightBlocks

- MaxSizePerMsg is also internal to etcd/raft, and it's defaulted
to PreferredMaxBytes in BatchSize, so that if a big block is created,
it is sent in a its own etcd/raft message, instead of being batched
with other blocks. This parameter takes effect when a batch of entries
is sent to lagged node. During normal replication, each block is
sent in its own message.
  It's not necessary to expose this config option to users.

- SnapInterval is renamed to SnapshotIntervalSize

FAB-14593 #done

Change-Id: Icaf2848a41c5f0f0a02f4b0b4a80ba852fddd584
Signed-off-by: Jay Guo <guojiannan1101@gmail.com>

There are presently two etcdraft protos around metadata.  One is the
metadata stored in the config and it is named 'Metadata', the other is
the metadata stored in each block, this is named 'RaftMetadata'.  This
causes confusion when reading the code.  This CR transforms those names
to be:

 Metadata -> ConfigMetadata
 RaftMetadata -> BlockMetadata

Change-Id: Ia0394ebe78f5541996c010c3c67d760f336f75d8
Signed-off-by: Jason Yellick <jyellick@us.ibm.com>

Instead of uint64 with unit Millisecond, use string in time
duration for TickInterval for etcdraft chain options, e.g. 500ms

Change-Id: I1549d4278654b04baa6e3ab6a93de1d9c453cdcc
Signed-off-by: Jay Guo <guojiannan1101@gmail.com>

This task focuses on testing the consensus-type migration "green" path,
that was introduced in FAB-13264.

The main contribution is in migration_test.go, which defines 3 test-cases
that test the green path. This is not the complete test suite for migration.
It is introduced in this stage to allow reviewers to get the full picture
of the feature defined in FAB-13264. The tests for the abort path and failure
scenarios will be added in later tasks.

The three test-cases are:

1. A test that executes the migration flow on the Kafka side
   (from START-TX until COMMIT-TX), on the system channel only.
2. A test that executes the migration flow on the Kafka side
   (from START-TX, CONTEXT-TX until COMMIT-TX), on the system
   channel and a single application channel. 
3. A test that executes the migration flow on the Raft side
   (from START-TX, CONTEXT-TX until COMMIT-TX, followed by restart
   of the orderer), on the system channel and a two application channel.

The tests are somewhat overlapping but are verifying different aspects of
the expected behavior. Overall, the tests verify that the flow of:

 - START-TX => CONTEXT-TX (x #std-channels) =>COMMIT-TX => Restart
   => (optional NONE-TX)

results in a functional etcdraft-based ordering service. That is, normal
transactions can be executed, and new channels can be created.
 

The task introduces some minor changes to the nwo test framework in order to
support the testing of the new feature:

 - Add OrdererCapabilites to Config, since kafka-to-raft migration is gates
   by a new V2_0 capability
   - add the following to tests that read the network config from file

     orderercapabilities:
       v20: false

 - Adds method to verify failure to update the OrdererConfig
 - Extends the configtx template to include support for the V2_0 orderer
   capability
 - Extend the network.go to
   - support V2_0 orderer capability
   - verify channel creation is blocked
   - support ConsensusType.Type changes
 - Extend standard_networks.go to
   - Support V2_0 orderer capability
   - define a Kafka2Raft and Kafka2RaftMultiChannel configurations for
     migration tests

Change-Id: I043b133b4c716f3bf53512f1999c7dfbc8aa67bb
Signed-off-by: Yoav Tock <tock@il.ibm.com>