Simplify the MDS Builder API

[abergs]

This PR aims to simplify the MDS builder API and adress some current problems we're seeing.

Developers today seems to believe it's hard / unfeasible to implement their own "caching" layer for MDS data.

• [API Proposal] Allow to disable caching for Metadata or use another cache mechanism  #550
• MetadataService/DistributedCacheMetadataService IDistributedCache dependency limitations #397

This is because we have not documented the current architecture properly, and the current builder pattern does indicate that there is not a lot of flexibility in the design, although the opposite is true.

This PR adds documentation, as well as reshapes the API to better surface the flexibility.

Example in the API change

Before

services
    .AddFido2(...)
    .AddCachedMetadataService(config =>
    {
        config.AddFidoMetadataRepository(httpClientBuilder =>
        {
            //TODO: any specific config you want for accessing the MDS
        });
    });

After:

  services
      .AddFido2(...)
      .AddFidoMetadataRepository()
      .AddCachedMetadataService();

We're also adding a two new builder methods, that makes it clear that you can register your own MDS Service to wrap the repositories, as well as custom repositories

Using FIDO mds repository + your own custom service to do caching, logging, storage, whatever

services
      .AddFido2(...)
      .AddFidoMetadataRepository()
+     .AddMetadataService<MyCustomMetadataService>();

Using a completely bespoke solution to fetch mds data and access it

services
      .AddFido2(...)
+     .AddMetadataRepository<MyCustomMetadataRepository>()
+     .AddMetadataService<MyCustomMetadataService>();

Breaking changes

This PR introduces some breaking changes in the API builder (compile time) and some run time breaking changes, namely: Removes the default registration of the NullMetadataService

• Remove the IFido2MetadataServiceBuilder
• Removes the default registration NullMetadataService

We are also adding plenty of comments as well as hiding the ConformanceMDS from Intellisense. I wonder if we should really remove it instead?

[abergs]

Please note, this PR does not actually add any new feature to the project. It does however help clarify how existing features can solve a users problem.

Does this suit your need @Simonl9l, @joegoldman2. Also curious if you have any thoughts @iamcarbon and @aseigler.

I've left it out of this PR, but I am interested in writing a FileSystemBlobRepository that sources the mds.jwt blob from the file system instead of multiple json files that the current FileSystemRepository and a "uncached" service that sits on top of it.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 78.34%. Comparing base (c0cdfc5) to head (7d8d117).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #620      +/-   ##
==========================================
+ Coverage   77.55%   78.34%   +0.79%     
==========================================
  Files          98       98              
  Lines        2539     2540       +1     
  Branches      422      422              
==========================================
+ Hits         1969     1990      +21     
+ Misses        460      440      -20     
  Partials      110      110              

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[abergs]

Checking in again if this solves your previous issues @Simonl9l, @joegoldman2?

[Simonl9l]

Checking in again if this solves your previous issues @Simonl9l, @joegoldman2?

@abergs we’re currently on a different path in this regard, and are no longer actively/currently using you package so defer to others.

thanks though for all you work on this package.

[joegoldman2]

@abergs this new API is more user-friendly, thank you for that. However, there is still something I don't really like and understand. The service is still strongly coupled to the cache, so it's mandatory to register IMemoryCache + IDistributedCached. Any chance we can have a version of IMetadataService without any cache mechanism and propose the cache as an opt-in feature?