bug: limit-count plugin,"group" peoperty result in 404 code

[jujiale]

Current Behavior

hello , when I use limit count plugin, I add two routes in etcd，the config like this below
route A:
{"id":"414182934216442808","create_time":1656401866,"update_time":1656908750,"uri":"/saveJsonUser*","name":"test1111","methods":["GET","POST","PUT","DELETE","PATCH","HEAD","OPTIONS","CONNECT","TRACE"],"plugins":{"limit-count":{"count":2,"disable":false,"group":"123456","key_type":"var","policy":"local","rejected_code":503,"time_window":30}},"upstream":{"nodes":{"172.xxx.xxx.xxx:8081":1},"timeout":{"connect":6,"send":6,"read":6},"type":"roundrobin","scheme":"http","pass_host":"pass","keepalive_pool":{"idle_timeout":60,"requests":1000,"size":320}},"status":1}
Route B:
{"id":"414220935969637304","create_time":1656424517,"update_time":1656901963,"uri":"/getIp","name":"getIp","priority":2,"methods":["GET","POST","PUT","DELETE","PATCH","HEAD","OPTIONS","CONNECT","TRACE"],"plugins":{"limit-count":{"count":2,"disable":false,"group":"123456","key_type":"var","policy":"local","rejected_code":503,"time_window":30}},"upstream":{"nodes":{"172.xxx.xxx.xxx:8081":1},"timeout":{"connect":6,"send":6,"read":6},"type":"roundrobin","scheme":"http","pass_host":"pass","keepalive_pool":{"idle_timeout":60,"requests":1000,"size":320}},"status":1}
you can see, I opend limit-count with the same propery "group" and other properties, but when I test invoke /getIp and /saveJsonUser, only one path cloud access, the other return 404, but when I just config one route (such as only routeA or routeB)，the access is OK.

Expected Behavior

I expect when I invoke routeA , it returns OK, when I invoke routeB , it returns OK also, when I used the count up ，it returns 503，because the two routes is in same "group"

Error Logs

I add some logs in source code, I find the problem occurs in the following:
apisix/plugins/limit-count.lua -> method name: check_schema
`

 for _, field in ipairs(fields) do
        if not core.table.deep_eq(prev_conf[field], conf[field]) then
            core.log.error("previous limit-conn group ", prev_conf.group,
                    " conf: ", core.json.encode(prev_conf))
            core.log.error("current limit-conn group ", conf.group,
                    " conf: ", core.json.encode(conf))
            return false, "group conf mismatched"
        end
    end

`
"prev_conf" has property "disable", but "conf" does not has propety "disable", so deep_eq return false.

then I use some way to avoid this, I find in apisix/plugin.lua -> method name:check_schema has following codes:
`

if plugin_obj.check_schema then
        local disable = plugin_conf.disable
        plugin_conf.disable = nil

        local ok, err = plugin_obj.check_schema(plugin_conf, schema_type)
        if not ok then
            return false, "failed to check the configuration of plugin "
                          .. name .. " err: " .. err
        end

        plugin_conf.disable = disable
    end

`
I do not understand why should "plugin_conf.disable = nil" before invoke "plugin_obj.check_schema", when I remove the "plugin_conf.disable = nil", the bug is disappear. I want to konw why should "plugin_conf.disable = nil"

I do not know if this is a bug, If not ,please tell me if my config has error or I ingore some other things.

Thank you!!!

Steps to Reproduce

1. create two routes
2. add limit count in the two routes,as below:

`

{"limit-count":{"count":2,"disable":false,"group":"123456","key_type":"var","policy":"local","rejected_code":503,"time_window":30}}

`
3.invode routeA and routeB , only one route could access, the other return 404

Environment

• APISIX version (run apisix version):v2.12.0
• Operating system (run uname -a):3.10.0-957.21.3.el7.x86_64
• OpenResty / Nginx version (run openresty -V or nginx -V):openresty/1.19.9.1
• etcd version, if relevant (run curl http://127.0.0.1:9090/v1/server_info):3.5.0
• APISIX Dashboard version, if relevant:
• Plugin runner version, for issues related to plugin runners:
• LuaRocks version, for installation issues (run luarocks --version):

[soulbird]

You can circumvent this problem by removing the disable field in the plugin first.

[jujiale]

@soulbird we use apisix-dashboard config the plugin, when I enable the plugin, the "disable:false" always be added