Switch to using the BCL HashCode type

[roji]

Also remove allocations from GetHashCode() methods by refraining from using LINQ.

Notes:

• I deliberately refrained from calling Aggregate() (or other LINQ) since we don't really want GetHashCode() to allocate.
• In at least some cases we should consider caching the hash code to avoid recomputing, but am leaving that for some other time. This is precisely why
• I've left out GetServiceProviderHashCode(), because it returns a long. Is there any specific reason we're return a long hash code rather than the standard int? Maybe we should change to int and use HashCode there as well?
• In cases where a class calls base.GetHashCode(), I simply passed that value HashCode.Combine() in the subclass. That means double-hashing occurs, which I think should be OK (opinions/insights??). Otherwise we'd need to expose getting a HashCode instance from base classes (not even possible with base classes we don't own, e.g. Expression).

[ajcvickers]

@roji Looks good to me. FYI @AndriySvyryd @smitpatel @bricelam @maumar Any concerns?

For the service provider hashing, see #13437. It's 64-bits to allow for more entropy, but it's unclear whether it really helps.

[roji]

Ah, I think I understand now - the hash code is being used as the actual key, as opposed to the standard way of having the object as the key (IDbContextOptions in this case), in which case there's an Equal() check.

Was it done this way for perf reasons or something?

[ajcvickers]

@roji It has a...history. ;-) It's certainly not something I am completely happy with, but it's also not clear how much value there is in re-working it.

[roji]

😆

OK. If we did want to change this, now would be a good time as changing the return value from long to int would be a breaking change.

[ajcvickers]

@roji That's true...but we could always postpone that change since we can still use a long type but with 32 unused bites. ;-)

[roji]

Sure, but if we're OK with having only 32-bits, we might as well just change the type to int now and do the breaking change, no?

[ajcvickers]

@roji I'm not okay with changing to 32-bits using the current design.

[roji]

Yeah, very understandable if you guys have already had some collisions. I may think about this a bit, but nothing urgent obviously.

[smitpatel]

[roji]

Converted a few more foreach's to for's and squashed, will merge after build.