Remove the implicit lifetime name requirement in the encoder_newtype macro

[nyonson]

Inspired by #5003 (which I believe is the elidable_lifetime_names clippy rule) I experimented with some lifetime elision in the encoder_newtype macro. This drops the implicit requirement that the encoder struct's lifetime be called 'e to match the internal macro's usage.

This might be a subtle change in the requirements themselves since they are no longer explicitly tied together, however, I haven't been able to come up with a unit test to break that in any way.

[apoelstra]

Wait, so now we're never tying the lifetime in the Encoder trait to the lifetime in the type? Do we even need the lifetime in the Encoder trait?

It seems like it's not actually used, and we can remove it entirely and stuff still works. Let's just do that.

[apoelstra]

--- a/consensus_encoding/src/encode/mod.rs
+++ b/consensus_encoding/src/encode/mod.rs
@@ -12,7 +12,7 @@
 pub trait Encodable {
     /// The encoder associated with this type. Conceptually, the encoder is like
     /// an iterator which yields byte slices.
-    type Encoder<'s>: Encoder<'s>
+    type Encoder<'s>: Encoder
     where
         Self: 's;

@@ -21,7 +21,7 @@ pub trait Encodable {
 }

 /// An encoder for a consensus-encodable object.
-pub trait Encoder<'e> {
+pub trait Encoder {
     /// Yields the current encoded byteslice.
     ///
     /// Will always return the same value until [`Self::advance`] is called.
@@ -52,7 +52,7 @@ macro_rules! encoder_newtype{
         $(#[$($struct_attr)*])*
         pub struct $name$(<$lt>)?($encoder);

-        impl<'e $(, $lt)?> $crate::Encoder<'e> for $name$(<$lt>)? {
+        impl<$($lt)?> $crate::Encoder for $name$(<$lt>)? {
             #[inline]
             fn current_chunk(&self) -> Option<&[u8]> { self.0.current_chunk() }

(and then update a bunch of impl sites)

[nyonson]

You mentioned there was a rust requirement with GATs that the trait needs an explicit lifetime even though its not used, so we can't drop it entirely right? 6e979a2

[apoelstra]

Yeah. I must have been wrong about that. I can definitely delete it and things still compile

But maybe we should first get #4982 in -- since that actually uses the GAT -- and then try this.

[nyonson]

@apoelstra looks like you are right! Updated the patch with your change.

[apoelstra]

ACK cf99839; successfully ran local tests; neat!