Revert "Catch wrong field names length in serde_test"

There are at least two reasonable things to expect the len field to
check: the length of the fields array passed to deserialize_struct, or
the number of field tokens. Even beyond these, in some cases it can be
useful to test deserialization with a bogus len to test how the
Deserialize impl reacts to an incorrect size_hint.

This reverts commit 436cafb0a3 which was
released in serde_test 1.0.20.

serde_test/src/de.rs

@@ -352,8 +352,8 @@ impl<'de, 'a> de::Deserializer<'de> for &'a mut Deserializer<'de> {
         V: Visitor<'de>,
     {
         match self.peek_token() {
-            Token::Struct { .. } => {
+            Token::Struct { len: n, .. } => {
-                assert_next_token!(self, Token::Struct { name: name, len: fields.len() });
+                assert_next_token!(self, Token::Struct { name: name, len: n });
                 self.visit_map(Some(fields.len()), Token::StructEnd, visitor)
             }
             Token::Map { .. } => {

serde_test/src/token.rs

@@ -425,10 +425,6 @@ pub enum Token {
 
     /// The header of a struct.
     ///
-    /// When testing deserialization, the `len` field must match the number of
-    /// fields that the struct expects to deserialize. This may be different
-    /// from the number of fields contained in the input tokens.
-    ///
     /// After this header are the fields of the struct, followed by `StructEnd`.
     ///
     /// ```rust
@@ -465,10 +461,6 @@ pub enum Token {
 
     /// The header of a struct variant of an enum.
     ///
-    /// When testing deserialization, the `len` field must match the number of
-    /// fields that the struct variant expects to deserialize. This may be
-    /// different from the number of fields contained in the input tokens.
-    ///
     /// After this header are the fields of the struct variant, followed by
     /// `StructVariantEnd`.
     ///