Sequential MIDs: on undecidable deduplication

[chrysn]

When implementing the advice in section 3.5 on "Deduplication with Sequential MIDs", I think that implementers will run into situations in which they can't tell whether a message was duplicate or not. (Eg. because the client sequentiality detection heuristic failed, or because a message was re-ordered by more than K messages, or because the simple MID storage mode memory overflew, or because the implementer didn't bother to implement simple MID storage mode b/c they knew it could overflow anyway).

For when the server can't tell whether the message is duplicate and the request is not idempotent, we should say something about how to fail safely. Options off my head would be an RST or a 5.03/Max-Age:0 (neither harming any observations b/c they're always safe and thus idempotent), with a slight preference for 5.03 as that's inviting the client to retry.

(Triggered by the discussion around core-wg/corrclar#6)