feat: ai rate limiting redis support

[beardnick]

Description

Which issue(s) this PR fixes:

Fixes #12482

Notice

• I have updated the limit-count-redis.lua and limit-count-redis-cluster.lua files to ensure they now support rate-limiting during the log phase.
• I referred to the limit-conn-redis.lua file as a guide while implementing rate-limiting in the log phase.
• To ensure a clean testing environment, I added the require("lib.test_redis").flush_all() function to every Redis rate-limiting test case. Without this addition, the tests could fail unpredictably.
• I have adjusted the expected results in limit-req-redis.t and limit-req-redis-cluster.t test cases. After thorough verification, the correct behavior is [200, 403, 403, 403]. Previously, the results appeared as [403, 403, 403, 403] due to Redis not being properly cleaned beforehand.

Checklist

• I have explained the need for this PR and the problem it solves
• I have explained the changes or the new features added to this PR
• I have added tests corresponding to this change
• I have updated the documentation to reflect this change
• I have verified that this change is backward compatible (If not, please discuss on the APISIX mailing list first)

[beardnick]

@Baoyuantop PTAL

[membphis]

@beardnick many thx for your contribution, some CI tests are failed, you can fix them

[membphis]

apisix/plugins/limit-count/util.lua

I checked _M.incoming and _M.log_phase_incoming, and they both work for redis.

We should add redis to the filename of the function name.

[AlinsRan]

This conditional statement is unnecessary, as an identical check is performed again a few lines later:

local delay, remaining, reset
    if not conf.policy or conf.policy == "local" then
        delay, remaining, reset = lim:incoming(key, not dry_run, conf, cost)
    else
        delay, remaining, reset = lim:incoming(key, cost, dry_run)
    end

And why do we need to perform two incoming operations during the log phase?