Add strong and weak ETag comparisons

[JunTaoLuo]

The implementation of Equals simply checks whether two ETags are equivalent but does not comform to the RFC's specifications in terms of comparing ETags listed here: https://tools.ietf.org/html/rfc7232#section-2.3.2.

cc @Tratcher

[JunTaoLuo]

Any reason we were going in a roundabout way of comparing strings previously? Why CompareOrdinal instead of Equals?

[Tratcher]

If you're going to use string.Equals you still need to pass in Ordinal

[JunTaoLuo]

The default is an ordinal comparison.

[Tratcher]

Always specify for string operations, the defaults are not consistant

[JunTaoLuo]

Interesting... How and when do they vary?

[troydai]

When then stars align ...

Also MSDN recommended use overload without default option.

We recommend that you select an overload that does not use default values, for the following reasons:

• Some overloads with default parameters (those that search for a Char in the string instance) perform an ordinal comparison, whereas others (those that search for a string in the string instance) are culture-sensitive. It is difficult to remember which method uses which default value, and easy to confuse the overloads.
• The intent of the code that relies on default values for method calls is not clear. In the following example, which relies on defaults, it is difficult to know whether the developer actually intended an ordinal or a linguistic comparison of two strings, or whether a case difference between protocol and "http" might cause the test for equality to return false.

[JunTaoLuo]

Fascinating, didn't know the defaults can vary in such ways. I guess it's always better to be on the safe side and just be explicit in what you want to do haha.

[troydai]

Being explicit greatly improves readability as it removes confusions.

[JunTaoLuo]

🆙📅

[Tratcher]