StringBuilderPool - Added unit test of MaxCapacity checks

[snakefoot]

Regression test for #3345

Figured out it was much easier to test the StringBuilderPool-directly, instead of trying to exercise the entire NLog-engine with many threads.

[304NotModified]

cool!

Can we maybe split this into 3 separate unit tests? We could use the ctor as test init for the large fields

[codecov-io]

Codecov Report

Merging #3353 into dev will increase coverage by <1%.
The diff coverage is n/a.

@@          Coverage Diff           @@
##             dev   #3353    +/-   ##
======================================
+ Coverage     80%     80%   +<1%     
======================================
  Files        356     356            
  Lines      28205   28205            
  Branches    3750    3750            
======================================
+ Hits       22559   22616    +57     
+ Misses      4540    4506    -34     
+ Partials    1106    1083    -23

[snakefoot]

Can we maybe split this into 3 separate unit tests?

Do what you like. But the different steps in the test are actually slowly moving the StringBuilderPool into the broken-state (that was possible before the bugfix)

[304NotModified]

the order of the RecursiveAcquirePoolItems calls is important, isn't?

[snakefoot]

Yes the call order of the recursive method is important for testing this. Tried to explain this with my code comments.

[304NotModified]

So we can't move to separate tests then?

[snakefoot]

You can make additional tests that are simpler than the initial one. But the initial test is important.