Fix SessionData counters across multiple errors

[imjoehaines]

Goal

The SessionData middleware is intended to keep counters for the number of handled and unhandled errors that occured in the current request. However it was not actually incrementing the counts, so the would always be reported as '1' or '0'

This change ensures that we tell the SessionTracker about the updated data, so the counters are correct

Changeset

Essentially the fix is to call SessionTracker::setCurrentSession after incrementing the counts, so that it can copy back the updated data. This method didn't used to be public, but it doesn't seem important to keep protected

There is technically also a small BC break in the SessionData constructor parameter has changed from Client to SessionTracker. This is because it only used the Client to get the SessionTracker anyway, so it might as well take the SessionTracker directly. I don't think this will affect many/any users, given this class is constructed internally in Client and not directly exposed. The change required to fix it is also minimal — pass SessionTracker instead of Client, which can be fetched from Client::getSessionTracker if necessary

Tests

I rewrote the SessionData tests to use less mocking — now only the SessionTracker HttpClient is mocked

I've also added tests to ensure that the counters persist between calls to the middleware — they run the middleware 5 times and assert the counts increment

Review

For the submitter, initial self-review:

• Commented on code changes inline explain the reasoning behind the approach
• Reviewed the test cases added for completeness and possible points for discussion
• A changelog entry was added for the goal of this pull request
• Check the scope of the changeset - is everything in the diff required for the pull request?
• This pull request is ready for:
  • Initial review of the intended approach, not yet feature complete
  • Structural review of the classes, functions, and properties modified
  • Final review

For the pull request reviewer(s), this changeset has been reviewed for:

• Consistency across platforms for structures or concepts added or modified
• Consistency between the changeset and the goal stated above
• Internal consistency with the rest of the library - is there any overlap between existing interfaces and any which have been added?
• Usage friction - is the proposed change in usage cumbersome or complicated?
• Performance and complexity - are there any cases of unexpected O(n^3) when iterating, recursing, flat mapping, etc?
• Concurrency concerns - if components are accessed asynchronously, what issues will arise
• Thoroughness of added tests and any missing edge cases
• Idiomatic use of the language