Add coverage for UnreservedUsernameValidator

[mjankowski]

The code path in the PAM/Rpam2 case was previously not exercised in the suite. While in there, I did some lightweight method-rename refactor on the validator itself. As far as I can tell the behavior is the same, and coverage is now 100%.

[mjankowski]

I don't see that CI failure locally and can't replicate with a few runs and modifications of things ... will keep attempting.

[nschonni]

Only guess is that it's related to the environment variables set here

mastodon/.github/workflows/test-ruby.yml

Lines 106 to 110 in 9caa047

	ALLOW_NOPAM: true
	PAM_ENABLED: true
	PAM_DEFAULT_SERVICE: pam_test
	PAM_CONTROLLED_SERVICE: pam_test_controlled
	BUNDLE_WITH: 'pam_authentication test'

Those came from CircleCI, and I never got a separate PAM-only job working when I tried before

[mjankowski]

Ah, thanks! -- it is indeed something in that block. When I set those all locally I'm able to replicate the failure.

I'll sort through that and see what's happening.

[renchap]

Can you use climate_control to set those variables in your spec?

[mjankowski]

Can you use climate_control to set those variables in your spec?

Some of them are related to what gems are loaded in the first place or what happens at initialization time of the whole app, and can't (or at least not as straightforwardly) be handled that way ... others, yes maybe.

[mjankowski]

Just pushed a change which I think may resolve things.

In my initial PR I had (erroneously!) changed the original code away from what it was doing before, which was that even if/when PAM was enabled, to still always check the reserved usernames in the settings. My initial PR changed this to either check the PAM settings or the site settings, but not both, which would have been a regression and I'm glad that CI run caught it.

I pushed something which restores the original behavior which is to let either pam OR the site settings flag a reserved name. Will watch CI to confirm that was the issue.