Correct defect with concurrency benchmarks (and add nested scope benchmark)

[alistairjevans]

When I was adding a new benchmark for testing nested scope concurrency, the concurrency test was taking absolutely forever, plus I got a CLR crash inside the GC, apparently an out of memory error.

I figured out why...it turns out the concurrency benchmark has never tested autofac concurrency, because at the end of the benchmark method, after building it calls:

Task.WhenAll(tasks)

This doesn't block, so it returns immediately, and the GC can't clean up the tasks. The benchmark was only testing how fast we can add tasks to a list.

When we add the appropriate wait:

Task.WhenAll(tasks).Wait()

The concurrency tests run in normal time, and do measure autofac performance.

Here's the updated latest develop benchmarks, including for the new benchmark I added.

BenchmarkDotNet=v0.12.0, OS=Windows 10.0.18362
AMD Ryzen 5 2500U with Radeon Vega Mobile Gfx, 1 CPU, 8 logical and 4 physical cores
.NET Core SDK=3.0.100
  [Host]     : .NET Core 3.0.0 (CoreCLR 4.700.19.46205, CoreFX 4.700.19.46214), X64 RyuJIT
  DefaultJob : .NET Core 3.0.0 (CoreCLR 4.700.19.46205, CoreFX 4.700.19.46214), X64 RyuJIT

Method	ResolveTaskCount	ResolvesPerTask	Mean	Error	StdDev	Gen 0	Gen 1	Gen 2	Allocated
MultipleResolvesOnMultipleTasks	100	100	1.727 ms	0.0342 ms	0.0407 ms	2542.9688	-	-	5.05 MB

Method	ConcurrentRequests	RepeatCount	Mean	Error	StdDev	Gen 0	Gen 1	Gen 2	Allocated
MultipleResolvesOnMultipleTasks	100	10	3.282 ms	0.0607 ms	0.0568 ms	3484.3750	-	-	6.9 MB

I'd suggest we run the updated benchmarks on the pending immutable changes before we merge those over.

[alexmg]

Good catch and nice to see another benchmark added to the list!