Set Guid version to 8 and embed reserve 4-bits for our own version "1" for now.

[Youssef1313]

Fixes #5957

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 0% with 6 lines in your changes missing coverage. Please review.

Please upload report for BASE (rel/4.0@40ff27c). Learn more about missing BASE report.

Files with missing lines	Patch %	Lines
...er.PlatformServices/ObjectModel/UnitTestElement.cs	0.00%	6 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             rel/4.0    #5974   +/-   ##
==========================================
  Coverage           ?   65.03%           
==========================================
  Files              ?      579           
  Lines              ?    32355           
  Branches           ?        0           
==========================================
  Hits               ?    21041           
  Misses             ?    11314           
  Partials           ?        0           

Flag	Coverage Δ
Debug	65.03% <0.00%> (?)
integration	65.03% <0.00%> (?)
production	65.03% <0.00%> (?)
unit	65.03% <0.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
...er.PlatformServices/ObjectModel/UnitTestElement.cs	65.97% <0.00%> (ø)

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Youssef1313]

From discussion with @tannergooding, the version field can be used by tools to interpret Guid in certain ways.

https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-1

Version 1 for example is for UTC timestamps and network card MAC address encoding.
Version 3 is for values computed by MD5, etc etc.

If we want to embed our own version while following the RFC properly, we should use version 8, and reserve other bits for embedding our "own" version.

Note that in the past, I think we never followed the RFC accurately, as we just hashed and passed that to Guid constructor, meaning we are creating random versions, and none of the tools reading TRX today tries to interpret the version following the spec. So we were mostly okay, but still we violated the spec.

In addition, XxHash128 output is big endian, so it's best if we do new Guid(hash, bigEndian: true) instead of new Guid(hash).

Note that there is not much of a concern of us using extra bits for reserving our version with regards to collision probability, as it's still very unlikely to practically see collisions.

I think that summarizes our discussion @tannergooding (hopefully accurately/correctly).

[Evangelink]

Approving but I'll let you merge once you get the confirmation.

[nohwnd]

Will rewrite in a way that touches single bytes.

[nohwnd]

Removed that complicated pointer logic, and instead we now edit just the appropriate bytes in the byte array. The byte array is always the same no matter if we are on big endian or little endian system, because endiannes only affects order of bytes, not order of bits within those bytes (and the hashing code handles it in a way that big endian is always returned).

This makes it very easy to find the bytes we need to edit. We edit the first half of the first byte (index 0), and set that to 0b0001. to set our version. The mask is "generated" by shifting the value 4 bits to the left, because it would be easy to specify the version as 0b1000 instead of the correct 0b1000_0000, so we would edit the wrong half of the byte.

The testcases changed a bit because I don't think the original code was correct.

Here a comparison of guid that is just letters a, shown as bits, before modification, after modification with the original code, and after modification with the new code:

[nohwnd]

• Still missing: setting the variant to 0b10 https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-8
• figure out if we need to swap the bytes when bigEndian is set but we don't have it available as api?

[nohwnd]

Finally correct, despite the inconsistencies in guid.

[nohwnd]

Final code, tested on big endian system (s390x + rhel) vs little endian system (just normal boring windows :D )