Allow to flatten IgnoredAny

[Mingun]

This can be useful for use-case described in #2432 (if other problems will be solved) and if you have a generic struct with flatten field and want to pass an IgnoredAny for whatever reason.

I also implement PartialEq for IgnoredAny so it can be tested using assert_de_tokens.

[dtolnay]

Independent of #2437, I am not sure whether this still has a use case. Could you let me know whether this PR is still needed?

For deserializing struct containing flattened fields from a map, I expect people would not need to write #[serde(flatten)] inner: IgnoredAny because ignoring all other fields is already the default behavior.

Thanks anyway for the PR!

[Mingun]

First of all, this is logical from consistency point-of-view.
Secondly, having this implementation allows to write a generic code:

#[derive(Deserialize)]
struct Generic<T> {
  my: String,
  fields: String,

  #[serde(flatten)]
  other: T,
}

type OnlyMyFields = Generic<IgnoreAny>;

It is better to preserve the principle of least astonishment:

• we have a generic field
• we know that we could pass any impl Deserialize type as generic parameter
• we know that we could ignore some value using IgnoredAny
• we know that IgnoredAny implements Deserialize
• we know that we could flatten any compound values
• we know that we could combine rules

So actually when mixing rules does not produce expected result, it is strange, especially if there is no any rationale explanations why their are not working.

[dtolnay]

Do we know of any code that uses or has wanted to use flatten in that manner with a generic type?

In general "least astonishment" is not compelling to me as it's in tension with "least bloat" and the intersection between features can be disproportionately costly to support for the sake of something that literally nobody might want in the first place.

[Mingun]

The point is not whether we know or not. I believe that the library should not limit the user to strange, not explained restrictions.

can be disproportionately costly to support

I think, that here definitely not this case. In fact, this PR decreases cost for support, because it removes special case and adds an explicit test for it. In contrast, in current situation you actually supports invariant that IgnoredAny cannot be type of the #[serde(flatten)] field, but you do that without a test that check that this invariant is hold.

[dtolnay]

Sounds good. Thanks for the PR!