redis: Add authentication support v2

[AmazingPP]

Replaces: #13851

Changes since v1:

• Reworked async mode to use a state machine for connection and authentication.
• Authentication is now retried on failure.
• Handled reply == NULL in the authentication callback.
• Added a guard: if a Redis username is set without a password, ignore the username and log a warning.

Manual testing

I manually tested the changes in both sync and async modes across different scenarios. All expected results matched actual results.

Case	Scenario	Result
1	No auth	Success, logs written
2	Wrong password	Connection failed, error logged
3	Correct password	Success, logs written
4	Missing password	Connection failed, error logged
5	ACL (valid)	Success, logs written
6	ACL (wrong password)	Connection failed, error logged
7	ACL (no username provided)	Connection failed, error logged
8	Re-authentication	Connection recovered, logs written after re-auth

Contribution style:

• I have read the contributing guide lines at
  https://docs.suricata.io/en/latest/devguide/contributing/contribution-process.html

Our Contribution agreements:

• I have signed the Open Information Security Foundation contribution agreement at
  https://suricata.io/about/contribution-agreement/ (note: this is only required once)

Changes (if applicable):

• I have updated the User Guide (in doc/userguide/) to reflect the changes made
• I have updated the JSON schema (in etc/schema.json) to reflect all logging changes
  (including schema descriptions)
• I have created a ticket at
  https://redmine.openinfosecfoundation.org/projects/suricata/issues

Link to ticket: https://redmine.openinfosecfoundation.org/issues/7062

Describe changes:

• Add authentication support to the Redis logging output.
• Authentication configuration defaults to null for backward compatibility.

[jasonish]

Seems to behave better. I haven't given it a thorough review yet, but I did notice that when authentication fails, it tends to retry harder, than when the connection fails. The main issue here is that it reconnects a lot more often than during a connection failure, and leads to some flooding of the logs. Is that intentional? Or a side affect?