Add configuration option to control what host is allowed to use FakeAuth

[floyd-may]

Use case

Building end-to-end testing such that writing e2e tests via Cypress (e.g.) I wouldn't have to instrument logging in via Azure AD, plus I wouldn't have to administer a testing-only AD account (e.g.) in order to validate that my app works correctly when logged in as a certain kind of user. The intent is to control it similar to this so that FakeAuth is only in play when it's needed:

var authBuilder = app.AddAuthentication();
var fakeAuthHost = Configuration["FakeAuthHost"];
if(!string.IsNullOrEmpty(fakeAuthHost)
{
    authBuilder.AddFakeAuth(opts => {
        opts.AllowedHost = fakeAuthHost;
    });
}

I'll likely use something like backend for the FakeAuthHost setting to match what I've configured in, say, a docker-compose.yml file.

I changed the claims serialization as well so that we can set the claims in a textual way instead of the binary serialization scheme that it was using.

(Fixes #13)

[floyd-may]

that build failure makes no sense - aren't I supposed to target Develop?

[calebjenkins]

"That build failure makes no sense"
.. agreed. I need to refactor the Workflows so that regression tests run, but right now it forces a fail if it's not actually on the develop branch. My GH Action -fu is weak sauce.

I like the idea of including a list of hosts, other than local. Much better than an on / off flag. I'm trying to think of scenarios where wild cards would be helpful in this scenario.. or if that opens up FA to too many opportunities for abuse.

I'll have time to take look more closely on this later today.

[floyd-may]

Me thinking about what kinds of horrors wildcards would open up:

I can get behind doing a list of hosts, though. LMK when you've had a chance to give it a think and if you still like it I'll update the PR accordingly.

[floyd-may]

Fixed the GH action thing too 😉

[calebjenkins]

@floyd-may I think this CI build to Nuget was published from the PR, it should only be published when a PR is merged to Develop. 😳 https://www.nuget.org/packages/FakeAuth/1.2.0-ci-61

[floyd-may]

@calebjenkins this ought to be ready to go. Also performed necessary incantations to get the ci actions workflow to only push to NuGet on the Develop branch.

[calebjenkins]

This is beautiful! 🤩🤩 So elegant!