This change set connects the block verification infrastructure
for onboarding to the production code.

Now, whenever an orderer onboards a channel - it also verifies the blocks
of the application channels, by:

1) Creating a bundle from the genesis block, which is derived from
   the system channel (which is verified using backward hash chain validation).
2) Verifying blocks using the bundle.
3) Replacing the bundle with a new bundle whenever a config block is pulled.

It also adds a check in the integration test, that ensures that no errors
are reported in the log of the onboarded OSN.

Change-Id: I3c5714f9d4491cdfd78e4e47407925136906d413
Signed-off-by: yacovm <yacovm@il.ibm.com>
Signed-off-by: Artem Barger <bartem@il.ibm.com>

This change set adds the following supporting structs for adding
support for verifying blocks pulled by onboarding in future CRs:

- Ledger interceptor: intercepts a commit of a block, and invokes
  a callback.

- VerificationRegistry: tracks commit of config blocks, and builds
  channelconfig bundles from them, in order to support verification
  of blocks pulled.

- BlockVerifierAssembler and BlockValidationPolicyVerifier: together
  they build block verifiers out of config blocks.

- verifierLoader: Loads a mapping of chainID->cluster.BlockVerifier,
  which is to be used at OSN startup to preload the existing verifiers.
  It is needed in cases we recover from a crash, or if we do
  dynamic onboarding and the previous config blocks have been committed
  to the ledger before the OSN was started.

In the next CR, I will wire all these into the onboarding infrastructure
itself, and they will be used to hold the latest bundle per channel
in order to verify block signatures.

Change-Id: Ic9fc99243baa5c2cef97103d001180207414d98a
Signed-off-by: yacovm <yacovm@il.ibm.com>

This change set moves etcdraft.LastConfigBlock to the
orderer common space, in order to be used for onboarding.

Change-Id: I218de927379831eee41e5689c56c409c35d77060
Signed-off-by: yacovm <yacovm@il.ibm.com>

This change set addresses golint warnings.

Change-Id: I5af4289ad669a829dd01587a85eeaef4146386db
Signed-off-by: yacovm <yacovm@il.ibm.com>

This change set makes cluster outgoing connections be asynchronous.
It is needed because etcdraft sends all messages in a blocking manner
as well as processes commands from the etcdraft library from the same
goroutine, and thus a node that is offline slows down
all messsage sending, and processing of messages.

Thus we make the connection creation asynchronous, and the book-keeping
for reconnecting to the offline nodes is done by the gRPC infrastructure.

Change-Id: I88268b1d67684c34bee71a126b01e2c237d2dcec
Signed-off-by: yacovm <yacovm@il.ibm.com>

This change set adds support for hash chain validation in presense
of configuration blocks that are found inside the block batches
being validated.

This is important because if a config block alters the validation rules
inside a batch, then validating the signature/certificates of the last
block in the batch needs to take into account the config block updates
themselves.

Change-Id: I03ef2a268ddc9ff63755d3a878f77d4814c5279d
Signed-off-by: yacovm <yacovm@il.ibm.com>

This change set prepares the block puller to be attached
to the etcdraft consenter and chain.

It adds the needed configuration in the orderer.yaml,
and also adds code that creates a block puller.

Change-Id: Ieb7c430613b16ba8625b323cdd8e170ed073ee1a
Signed-off-by: yacovm <yacovm@il.ibm.com>

This change set adds extraction of TLS CA certificates
from a configuration block.

Change-Id: I00f82bfcbdac19463768f6f74accef70d47d508e
Signed-off-by: yacovm <yacovm@il.ibm.com>

This change set adds hash chain validation utilities for the deliver
client for an ordering service node of a cluster type, to be used
for replication between ordering nodes.

Change-Id: Ic604558a3d47752da4898ef1e25e982eaf178f86
Signed-off-by: yacovm <yacovm@il.ibm.com>

This change set implements a base communication layer for
the raft orderer, but it can actually be used for any
consensus protocol that has:
- A specified number of members at any given point in time
- uses TLS pinning for identification
- Represents members as integers

The communication has 3 basic capabilities:

1) Obtain a remote context given a destination node ID and a channel
2) Configure the communication on the context of a given channel
3) Get notified of Step() and Submit() messages from other remote nodes

Change-Id: I87f193b7723f95f359cc4071e28b362be703ab74
Signed-off-by: yacovm <yacovm@il.ibm.com>