Replace Bouncy Castle package

[rubo]

Changes

• Replaced the Portable.BouncyCastle package with the latest official BouncyCastle.Cryptography one as per @flcl42 request
• As a result, removed and replaced our AesEngineX86Intrinsic with the one of Bouncy Castle that already has the improvements from @benaadams
• Removed Pyroscope as referencing it doesn't have any effect

Types of changes

What types of changes does your code introduce?

• Bugfix (a non-breaking change that fixes an issue)
• New feature (a non-breaking change that adds functionality)
• Breaking change (a change that causes existing functionality not to work as expected)
• Optimization
• Refactoring
• Documentation update
• Build-related changes
• Other: Description

Testing

Requires testing

• Yes
• No

If yes, did you write tests?

• Yes
• No

Remarks

Benchmarks of replacing AesEngineX86Intrinsic (BenchmarkAdams):

| Method         | Mean     | Error    | StdDev    | Median   |
|--------------- |---------:|---------:|----------:|---------:|
| DotnetOSNative | 73.51 ns | 7.217 ns | 21.280 ns | 56.19 ns |
| BenchmarkAdams | 33.40 ns | 2.735 ns |  8.065 ns | 29.45 ns |
| BouncyCastle   | 24.45 ns | 0.491 ns |  0.504 ns | 24.56 ns |

The results differ slightly on each run, but BouncyCastle and BenchmarkAdams are always nearly the same, with BouncyCastle being slightly faster. In the run above, it's noticeably faster. Regarding OS native implementation, I suspect that it doesn't use hardware acceleration, and that may be because of the configuration the .NET runtime invokes it with. But that's just a guess.

[benaadams]

• Removed Pyroscope as referencing it doesn't have any effect

Is to have the dll on the otherside so that it can be switched on in graphana if desired; otherwise you'd need a custom docker container on top of our container to include it

[benaadams]

Regarding OS native implementation,

The runtime plays it very safe and conservative with their cyrptography use and entirely depends on which native version you have installed at platform level, and are very resistant to any optimizations in that area (i.e. they don't want any responsibility for encryption)

[rubo]

The runtime plays it very safe...

Yeah, I know their approach to that. I'm wondering why the OS native implementation doesn't use hardware acceleration; otherwise, it wouldn't be that slower than the other two. So, I assume it could be that the .NET runtime invokes either unoptimized (as you said, conservative) versions or doesn't pass some parameters to turn hardware acceleration on. But that's just a speculation; I haven't checked the code.