Adding withCertificate overload to use cert serial number

[trwalke]

Fixes #
#5150

Changes proposed in this request
The new WithCertificate(X509Certificate2 certificate, bool sendX5C, bool associateTokensWithCertificateSerialNumber) api enables MSAL to add the certificate serial number to the cache key using the new cache key extension.

This is certificate serial number is added at the application level and is intended to enable app tokens to be associated with the certificate serial number for every request.

This api internally calls WithAdditionalCacheKeyComponents(Dict<string, string>) to further partition the cache key by cert serial number.

Testing
Unit tests
Manual testing

Performance impact
N/A

Documentation

• All relevant documentation is updated.

[gladjohn]

Please add the following tests,

• Validate Cache Partitioning with Different Certificates
• Verify Token Retrieval from Cache
• Validate Behavior When associateTokensWithCertificateSerialNumber is False
• Ensure Cache Key is Formed Correctly

Would adding an integration test add any value here?

[trwalke]

Please add the following tests,

• Validate Cache Partitioning with Different Certificates
• Verify Token Retrieval from Cache
• Validate Behavior When associateTokensWithCertificateSerialNumber is False
• Ensure Cache Key is Formed Correctly

Would adding an integration test add any value here?

The underlying api has tests that are already validating cache partitioning/cache key format/token retrieval from cache.

This is one of those scenarios where I am trying to decide how much testing should be done if the underlying api (WithAdditionalCacheKeyComponents(Dict<string, string>)) already has tests for a lot of this functionality. the new api is simply calling an already existing api without much additional logic so my tests here are focusing on new logic.

Seems like an interesting discussion @gladjohn @bgavrilMS

However, I agree that I can test the false case for the api.

[gladjohn]

Please add the following tests,

• Validate Cache Partitioning with Different Certificates
• Verify Token Retrieval from Cache
• Validate Behavior When associateTokensWithCertificateSerialNumber is False
• Ensure Cache Key is Formed Correctly

Would adding an integration test add any value here?

The underlying api has tests that are already validating cache partitioning/cache key format/token retrieval from cache.

This is one of those scenarios where I am trying to decide how much testing should be done if the underlying api (WithAdditionalCacheKeyComponents(Dict<string, string>)) already has tests for a lot of this functionality. the new api is simply calling an already existing api without much additional logic so my tests here are focusing on new logic.

Seems like an interesting discussion @gladjohn @bgavrilMS

However, I agree that I can test the false case for the api.

added negative testing looks good.

[gladjohn]

🚢

[bgavrilMS]

@trwalke - please remove this.