proto: Refactor TokenDecodeError

[gretchenfrage]

This PR consists solely of renames and docs changes.

• Renames enum TokenDecodeError -> ValidationError

  TokenDecodeError is used when that there was an error decoding a token, but is also when there was no error decoding the token but the token contained an address not applicable to the current situation. Thus, this rename more accurately reflects the purpose of the error.

• Renames variant UnknownToken -> Unusable Ignore

  UnknownToken is used when a token cannot be decoded or deserialized, and triggers the token to be ignored. Thus, it's name is currently an accurate description of how it's used, however, I found it very confusing why we use it like that, and had to get Ralith to explain it to me. Moreover, in the future, this error would be applicable to situations where a token can be unambiguously decrypted/decoded as a token from a NEW_TOKEN frame, but is simply not valid. In that situation, the variant name would cease to be an accurate description of how it's used. Thus, we rename it to a more accurately describe the sorts of situations it would apply to, and leave a detailed comment on the variant explaining the rationale. Relatedly, we remove a comment from endpoint.rs for being now-redundant.

  At one point, in Utilize NEW_TOKEN frames #1912, I tried the name InvalidMaybeNewToken, but Ralith seemed hesitant. While that name was more descriptive, it's also pretty cumbersome.

• Renames variant WrongAddress -> InvalidRetry

  WrongAddress is used when a token can be successfully decoded and deserialized but has the wrong client address, and triggers the connection to be closed. Thus, it's name is currently an accurate description of how it's used. However, if in the future we start processing tokens from NEW_TOKEN frames, this error would not be applicable to situations where a token can be unambiguously decrypted/decoded as a token from a NEW_TOKEN frame but has the wrong client address, as the appropriate way to handle that situation would be to ignore the token rather than close the connection, so we would have to use a different error. In that situation, the variant name would cease to be an accurate description of how it's used. Thus, we rename it to a more accurately describe the sorts of situations it would apply to.

  An additional conceivable benefit of this name is that it would make it easier to potentially add future cases where a token can be unambiguously identified as a token from a Retry packet, but still cannot be fully decrypted or deserialized, or where it is otherwise for some reason unusable.

[djc]

Nice!