Uses correct zero value for lgpo LockoutDuration

[lorengordon]

What does this PR do?

Updates win_lgpo execution module to use the correct zero value for LockoutDuration

What issues does this PR fix or reference?

Fixes #56406

Previous Behavior

Setting the LockoutDuration to 0 with certain combinations of LockoutThreshold and LockoutWindow would throw a CommandExecutionError.

New Behavior

The LockoutDuration zero value is set correctly.

Tests written?

Yes

Commits signed with GPG?

Yes

[Ch3LL]

There is a merge conflict here that needs to be resolved and pre-commit is failing.

[lorengordon]

@Ch3LL I believe I fixed it up, but I do not use pre-commit and don't plan to start just for this project. If the test outputs the diff it wants, I'll be happy to apply it.

[Ch3LL]

yep it does. you can see it here:

https://jenkinsci.saltstack.com/job/pr-pre-commit/job/PR-56408/2/console

[lorengordon]

Ok, resolved the conflict, and pre-commit is good now!

[lorengordon]

@Ch3LL here's a nifty looking github action that might simplify the black requirement for prs... https://github.com/cclauss/autoblack

[Ch3LL]

thanks for updating with that diff, appreciate it.

thanks for linking that tool. It does look like that tool will edit the code for the user. ping @s0undt3ch and @waynew i know you two were stewarding the black project. I faintly remember there being a reason we didn't want to automatically edit the code for the user?

[s0undt3ch]

https://github.com/cclauss/autoblack#tldr-it-does-not-work

[Ch3LL]

ping @twangboy this is awaiting your re-review

[lorengordon]

@s0undt3ch well that's a bummer. I dug a little more and found a solution using comments to dispatch and process commands. Looks rather a bit more involved to setup. But still would be a lot of value for a project with as many contributors as salt. Maybe some chatbot, or your own Jenkins server, could do it?