Added benchmarks for V1-V4 for encrypt, decrypt, sign and verify

[TimothyMakkison]

Created some Benchmarks that cover both versions of .net, all protocol versions, both purposes and each form of encode/decode. Not sure how to structure/name it so created a benchmarks folder and added .Benchmark suffix.

The benchmarks work and appear to give realistic values with the exception of Verify/Sign in V1 and V3. All other operations typically take 40-120 us and allocate 20 KB of memory, whereas V1 and V3 Verify/Sign take up to 8,400 us and allocate 7000 KB of memory. Is this due to bouncy castle implementation or should this be expected with RSA?

[codecov-commenter]

Codecov Report

Merging #84 (b2636a9) into master (ff8f017) will increase coverage by 0.14%. The diff coverage is n/a.

@@            Coverage Diff             @@
##           master      #84      +/-   ##
==========================================
+ Coverage   82.39%   82.53%   +0.14%     
==========================================
  Files         104      104              
  Lines        5293     5285       -8     
  Branches      329      328       -1     
==========================================
+ Hits         4361     4362       +1     
+ Misses        807      800       -7     
+ Partials      125      123       -2     

Impacted Files	Coverage Δ
src/Paseto/Cryptography/Sha512.cs	88.40% <0.00%> (+6.21%)	:arrow_up:
...eto/Cryptography/Internal/Ed25519Ref10/sc_clamp.cs	100.00% <0.00%> (+50.00%)	:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[daviddesmet]

There are some improvements needed in regards to memory allocation but 7000 KB memory is quite a lot, my guess is that it could be related to bouncy castle but we might need to isolate those methods we use on bouncy castle in order to verify it.

Nonetheless, thanks for adding some benchmarks, it will help us on seeing where we are standing and where we could improve.

[TimothyMakkison]

I've been thinking about playing around with bouncy castle for a while now. I ran some analysis on V3 Sign/Verify and it looks like the bulk of allocations (and presumbaly time spent) is on Multiply where a huge number of BouncyCastle.BigInteger instances are created, not sure if this can be avoided but I'd like to see how using System.Numerics.BigInteger affects performance.

Would you consider adding benchmark-action?

[daviddesmet]

Sounds good! Regarding the benchmark action, I'm looking into it, thanks for the suggestion!