Increase poll::Validate visibility to pub

Previously, poll::Validate was pub(crate) to force external implementors
of Poll to define their implementation in terms of ChainPoller. This was
because ChainPoller::look_up_previous_header checks for consistency
between headers and any errors would be checked at that level rather
than by the caller. Otherwise, if performed by the caller, a Poll
implementation would not be aware if the underlying BlockSource was
providing bad data and therefore couldn't react accordingly.

Widening the visibility to pub relaxes this requirement, although it's
still encourage to use ChainPoller to implement Poll. This permits
either copying or moving lightning-block-sync's test utilities to a
separate crate since they use poll::Validate.

Author: jkczyz

lightning-block-sync/src/poll.rs

@@ -44,7 +44,9 @@ pub enum ChainTip {
 }
 
 /// The `Validate` trait defines behavior for validating chain data.
-pub(crate) trait Validate {
+///
+/// This trait is sealed and not meant to be implemented outside of this crate.
+pub trait Validate: sealed::Validate {
 	/// The validated data wrapper which can be dereferenced to obtain the validated data.
 	type T: std::ops::Deref<Target = Self>;
 
@@ -156,10 +158,18 @@ impl std::ops::Deref for ValidatedBlock {
 	}
 }
 
+mod sealed {
+	/// Used to prevent implementing [`super::Validate`] outside the crate but still allow its use.
+	pub trait Validate {}
+
+	impl Validate for crate::BlockHeaderData {}
+	impl Validate for bitcoin::blockdata::block::Block {}
+}
+
 /// The canonical `Poll` implementation used for a single `BlockSource`.
 ///
-/// Other `Poll` implementations must be built using `ChainPoller` as it provides the only means of
-/// validating chain data.
+/// Other `Poll` implementations should be built using `ChainPoller` as it provides the simplest way
+/// of validating chain data and checking consistency.
 pub struct ChainPoller<B: DerefMut<Target=T> + Sized , T: BlockSource> {
 	block_source: B,
 	network: Network,