Do not return stored password on first retry

[fmeum]

📢 Type of change

• Bugfix
• New feature
• Enhancement
• Refactoring
• Dependency updates

📜 Description

Do not return the stored password when asked for a retry.

💡 Motivation and Context

We are currently returning an incorrect stored password even though we know it's incorrect and should really ask the user for a new entry.
This issue has been present for a few stable versions now, but only becomes relevant when using HTTPS authentication with servers that return a WWW-Authenticate header on failed authentication attempts. Gitea doesn't do this, I don't know who does, so it's not clear whether we should backport this or not.

Note that this never affects SSH passphrases since we get infinite retries there and this just eats up a single one.

💚 How did you test it?

📝 Checklist

• I formatted the code with the IDE's reformat action (Ctrl + Shift + L/Cmd + Shift + L)
• I reviewed submitted code
• I added a CHANGELOG entry if applicable

🔮 Next steps

📸 Screenshots / GIFs

[fmeum]

Let's not merge this non-backported fix yet and give the reporter a chance to verify their issue is resolved by the snapshot build.

[fmeum]

The reporter is unfortunately not able to test prior to release. I went through all the work flows I could image with Gitea via HTTPS (wrong password/correct password with/without remembering, sync/push/pull) and everything worked fine.

@msfjarvis Once you have confirmed everything works for you with the backported fixes, feel free to merge this.

[msfjarvis]

The reporter is unfortunately not able to test prior to release. I went through all the work flows I could image with Gitea via HTTPS (wrong password/correct password with/without remembering, sync/push/pull) and everything worked fine.

@msfjarvis Once you have confirmed everything works for you with the backported fixes, feel free to merge this.

I just began backporting and #1060 seems to not actually be a backport candidate, since the code in the release branch is correct AFAICT (formatting notwithstanding). I've picked #1062 though.

[fmeum]

The reporter is unfortunately not able to test prior to release. I went through all the work flows I could image with Gitea via HTTPS (wrong password/correct password with/without remembering, sync/push/pull) and everything worked fine.
@msfjarvis Once you have confirmed everything works for you with the backported fixes, feel free to merge this.

I just began backporting and #1060 seems to not actually be a backport candidate, since the code in the release branch is correct AFAICT (formatting notwithstanding). I've picked #1062 though.

Oh, that's true, glad that #995 has not been released then. #1062 certainly needs to go in though.