caddytls: verifier: caddyfile: re-add Caddyfile support

[mohammed90]

This was inadvertently missed during #5784. Re-adding Caddyfile support with a test of a dummy verifier to ensure it isn't broken in the future. I know LeafCertClientAuth is there, but it doesn't have Caddyfile support. This PR is faster to fix the gap until the LeafCertClientAuth module supports Caddyfile.

CC/ @Gr33nbl00d

[mohammed90]

The namespace of the verifiers isn't optimal. It's under tls.client_auth. It's better if it were under tls.client_auth.verifier, but unsure how much breakage that'd cause.

[francislavoie]

I think it's just the one plugin which uses it, so I think it might be okay to change the namespace if @Gr33nbl00d agrees.

[Gr33nbl00d]

Usually i am not a big fan of breaking changes for just better naming. But i agree if you think its better this way and woth it i will create a version 2 of my plugin which works for caddy 2.8.0+

[francislavoie]

Unfortunately because of how Go works, a v2 would be a new module ID. I'd recommend just staying at v1 indefinitely to avoid that. Just bump the go.mod to require Caddy 2.8.0 as minimum.

[Gr33nbl00d]

Unfortunately because of how Go works, a v2 would be a new module ID. I'd recommend just staying at v1 indefinitely to avoid that. Just bump the go.mod to require Caddy 2.8.0 as minimum.

Ah ok then i will do so thanks for the hint :)

[mohammed90]

Unfortunately because of how Go works, a v2 would be a new module ID. I'd recommend just staying at v1 indefinitely to avoid that. Just bump the go.mod to require Caddy 2.8.0 as minimum.

Ah ok then i will do so thanks for the hint :)

Also you're not breaking your users. We're breaking your module. So the v2 isn't necessary anyways. As Francis said, just make a new tag that depends on Caddy v2.8.0.

I'll push the commit later.

[Gr33nbl00d]

Unfortunately because of how Go works, a v2 would be a new module ID. I'd recommend just staying at v1 indefinitely to avoid that. Just bump the go.mod to require Caddy 2.8.0 as minimum.

Ah ok then i will do so thanks for the hint :)

Also you're not breaking your users. We're breaking your module. So the v2 isn't necessary anyways. As Francis said, just make a new tag that depends on Caddy v2.8.0.

I'll push the commit later.

Not completly true. If that compiler limitation wouldnt be there it makes sense. If you want to still be able to compile against older version of caddy it makes usually sense to create a new major version as this is not backward compatible change. If i would need to submit urgent hotfixes. Users will be forced to update to latest caddy otherwise. I usually would create a new v1 branch for maintenance purpose and continue v2 on main. So i can still release v1 hotfixes.