Add option to authenticate to an upstream mirror

[Splamy]

• Allows users to authenticate to an upstream mirror with Basic, Bearer or Custom Header Auth

Addresses https://github.com/orgs/bagetter/discussions/88

Open questions:

• Do you prefer logically tied classes in on file or in separate (MirrorOptions, MirrorAuthenticationOptions, MirrorAuthenticationType) ?
• Since this feature is more or less just piping configuration through to the httpclient I had a hard time creating good unit tests and ended up making integration-ish tests.
  A lot of the composition is done via DI and private methods so there are also little points to mock nicely.
  If you have any suggestions or requests to improve this, I'm open.
  I've also considered adding a dedicated mocking library for http requests to reduce boilerplate, but would like your feedback first before adding new depencies to a project.

[FroggieFrog]

First thank you for the PR! It will be a valuable addition to the project.
I haven't run or checked the PR yet, but what caught my eye is the documentation.
First I have to say good job. Good use of the Tabs feature 😀
I think this addition justifies a separate page under the Configuration category to prevent cluttering the page.
So my suggestion is the following structure:

• Configuration
  • Mirror (read-through caching)

The new page should contain the existing documentation for this feature and the new additional configuration.

To answer one of your questions: I personally prefer one class/enum/struct per file.

[loic-sharma]

This is awesome, excellent work!

I would consider allowing Windows user to opt-in to encrypting their secret using DPAPI, but definitely not a blocker to landing this.

[Regenhardt]

Thanks for the great addition!

[Splamy]

Thanks for the feedback, will try to address as soon as I can.

This is awesome, excellent work!

I would consider allowing Windows user to opt-in to encrypting their secret using DPAPI, but definitely not a blocker to landing this.

Interesting idea. Adding this will also need to have a proper ux for that. Either a cli command creating the hashed pw, or creating and updating the field in the appsettings (though appsettings aren't supposed to be automatically written since you will lose formatting and comments).
Maybe ./BaGetter.exe encrypt-password pass123 to stdout like caddy does

[Splamy]

I think I've adressed everything including the feedback from @FroggieFrog.

[FroggieFrog]

Your original issue was the authentication against a GitHub feed if I remember correctly.
So we could test it by releasing BaGetter packages on a GitHub feed 😬

[Splamy]

For using as a test feed yeah, for actual distribution more only as a gimmick :P

[seriouz]

I think there is nothing wrong when we publish BaGetter on NuGet and here on GitHub. At least from my point of view, there is nothing to be said against it.

[Splamy]

Sorry for the late update. Somehow oversaw the review response.
Updated the check and rebased to latest main.

[Regenhardt]

Back from vacation! Looks great, just a minor change. Has anyone tested this yet? Otherwise I'll gladly checkout and test it.

[vlada-dudr]

Can I help with something to get this merged?

[Regenhardt]

Can I help with something to get this merged?

I will merge it like this, would appreciate it if you made another PR to improve the exception message there.

[Regenhardt]

The last remaining comment from before can be worked on after it is merged too.