reuse the identity policy in the reconnect that has been used in the connect

[KircMax]

Proposed changes

Describe the changes here to communicate to the maintainers why we should accept this pull request. If it fixes a bug or resolves a feature request, be sure to link to that issue.

Related Issues

• Fixes The PolicyId that has been used to activate the session is not used for reconnect ("reactivatesession") #2525

Types of changes

What types of changes does your code introduce?
Put an x in the boxes that apply. You can also fill these out after creating the PR.

• Bugfix (non-breaking change which fixes an issue)
• Enhancement (non-breaking change which adds functionality)
• Test enhancement (non-breaking change to increase test coverage)
• Breaking change (fix or feature that would cause existing functionality to not work as expected, requires version increase of Nuget packages)
• Documentation Update (if none of the other choices apply)

Checklist

Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

• I have read the CONTRIBUTING doc.
• I have signed the CLA.
• I ran tests locally with my changes, all passed.
• I fixed all failing tests in the CI pipelines.
• I fixed all introduced issues with CodeQL and LGTM.
• I have added tests that prove my fix is effective or that my feature works and increased code coverage.
• I have added necessary documentation (if appropriate).
• Any dependent changes have been merged and published in downstream modules.

Further comments

If this is a relatively large or complex change, kick off the discussion by explaining why you chose the solution you did and what alternatives you considered, etc...

[KircMax]

I also added passing the cancellationtoken to the factory method but I can also undo it if you want - just noticed that the cancellationtoken exists and is not passed.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (2b9d8f9) 53.81% compared to head (85aac28) 46.52%.
Report is 5 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #2526      +/-   ##
==========================================
- Coverage   53.81%   46.52%   -7.30%     
==========================================
  Files         334      284      -50     
  Lines       64409    58025    -6384     
  Branches    13235    11852    -1383     
==========================================
- Hits        34663    26994    -7669     
- Misses      25990    27829    +1839     
+ Partials     3756     3202     -554     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[mregen]

@mrsuciu had been looking into policyId issues recently, please code review as well.

[mrsuciu]

@KircMax Does the second "FindUserTokenPolicy(m_identity.TokenType, m_identity.IssuedTokenType)" make any difference (is it ever going to get executed) ? If its purpose is to take into account a PolicyId change on the server side during the disconnect time, I still cannot see a renewal of the m_endpoint.Description being made in the reconnect scenario path...

[KircMax]

I was not really sure...
I am not too familiar with the codebase and wanted to keep the changes 'defensive' but my feeling was it should never be necessary...
I'd also not really expect a server that had PolicyId changes during the disconnect time be able to reactivate a session that has been before that change, therefore I think we could also get rid of that second "FindUserTokenPolicy(m_identity.TokenType, m_identity.IssuedTokenType)" either way.
Of course that feeling might be wrong for some certain servers but as you said we are not updating the m_endpoint.Description anyways...

[KircMax]

--> I'll remove the second one and push the update.