Allow Multiple Bridge Pallet Instances (#226)

* Add Instance type parameter to pallet

* Sketch out what the runtime could look like

* Allow runtime to compile with multiple bridge pallets

* Cargo Fmt

* Allow an instance of a PoA chain to be used with currency-exchange

I specify that it's only _an instance_ instead of _instances_ since the currency-exchange
pallet does not support multiple instances itself. What this commit does is make it so
that the different instances of the PoA chains we currently have are compatible with the
currency-exchange pallet through the implementation of the PeerBlockchain trait.

* Add Instance type parameter to Currency Exchange pallet

* Wire up currency exchange intances in runtime

* Rust Fmt

* Show sccache

* Allow Eth pallet to use a default instance

* Use a default instance in Eth pallet tests

* Remove Rialto and Kovan feature flags

Through some discussions it has been decided that the `bridge-node` should, like
Substrate's `node-template`, be a showcase of the different pallets available in
a project. Because of this I've removed the feature flags for the Rialto and Kovan
networks in favour of having both of them included in the runtime.

* Update the chain_spec to use both Rialto and Kovan configs

* Update pallet level calls used by Substrate client

Allows the project to compile. However, it should be noted that in reality
we shouldn't be hardcoding the pallet we're calling.

* Allow currency-exchange pallet to use a default instance

* Support benchmarking an instance of the Eth pallet

* Update currency exchange benchmarks to work with instances

* Fix test helpers which now need a PoA instance

* Remove Actions for checking Rialto and Kovan features

* Add missing comments

* Update Runtime API string constants

* Add issue number for generic chain support in relay

* Add Runtime APIs for instances of the currency-exchange pallet

* Rust Fmt

Co-authored-by: Denis S. Soldatov aka General-Beck <general.beck@gmail.com>

bridges/primitives/ethereum-poa/src/lib.rs

@@ -505,19 +505,32 @@ pub fn step_validator<T>(header_validators: &[T], header_step: u64) -> &T {
 }
 
 sp_api::decl_runtime_apis! {
-	/// API for headers submitters.
-	pub trait EthereumHeadersApi {
+	/// API for querying information about headers from the Rialto Bridge Pallet
+	pub trait RialtoHeaderApi {
 		/// Returns number and hash of the best block known to the bridge module.
-		/// The caller should only submit `import_header` transaction that makes
+		///
+		/// The caller should only submit an `import_header` transaction that makes
 		/// (or leads to making) other header the best one.
 		fn best_block() -> (u64, H256);
-
 		/// Returns number and hash of the best finalized block known to the bridge module.
 		fn finalized_block() -> (u64, H256);
-
 		/// Returns true if the import of given block requires transactions receipts.
 		fn is_import_requires_receipts(header: Header) -> bool;
+		/// Returns true if header is known to the runtime.
+		fn is_known_block(hash: H256) -> bool;
+	}
 
+	/// API for querying information about headers from the Kovan Bridge Pallet
+	pub trait KovanHeaderApi {
+		/// Returns number and hash of the best block known to the bridge module.
+		///
+		/// The caller should only submit an `import_header` transaction that makes
+		/// (or leads to making) other header the best one.
+		fn best_block() -> (u64, H256);
+		/// Returns number and hash of the best finalized block known to the bridge module.
+		fn finalized_block() -> (u64, H256);
+		/// Returns true if the import of given block requires transactions receipts.
+		fn is_import_requires_receipts(header: Header) -> bool;
 		/// Returns true if header is known to the runtime.
 		fn is_known_block(hash: H256) -> bool;
 	}