sync fast cloner to 3.5.3

[lofcz]

This reverts a custom patch added to FastCloner in f199294 and syncs to upstream v3.5.3. There was indeed a bug in v3.5.2 (sorry about that) - but the custom patch here is wrong and could cause bugs. See lofcz/FastCloner@9eb89d3#diff-84e02a68b92cb9aa70d119689ba40fb38eb9165edd0b751e30aa3f93b21d4d8fR261 - the custom patch would fail this test.

Verified both test harnesses pass.

[lofcz]

@niemyjski I believe the failing test here on the provisioned runner is unrelated to the cloning.

failed Foundatio.Tests.Queue.InMemoryQueueTests.CanQueueAndDequeueMultipleWorkItemsAsync
Test run summary: Failed!
total: 1809
failed: 1
succeeded: 1795
skipped: 13
duration: 1m 23s 604ms

[lofcz]

@niemyjski looked into the failing thing out of curiosity in 4744fc1 - xunit creates a new test class instance of InMemoryQueue per test, which registers ObservableGauge with the same name on shared Meter. They keep firing after prior test resolve, so MeterListener gets measurments from both active and disposed queues, with very close timestamps. Value<long>() then picks the latest - which is non-deterministic, if timestamps tie. So we return [] instead of 0 on disposed queues to properly signal "no data".

[niemyjski]

Thank you, I'll take a look into it. Was just deep diving into how I can make those meters better as it's kind of sync/async problem too.

Also I wanted to log an issue for this as well but I noticed when I run dotnet format on the project it formats all of these files and I have an active branch open for enabling nullable reference types (dotnet/skills for implementing it was super easy) which resulted in more changes. I'd be happy to open a pr for either but it might be more back and forth than a quick commit.