* refactor(authz): macro move to hrl and rename, add meta example
* refactor(authz_api_mnesia): use config schemas for request validations
* chore(authz_api_mnesia): suite module typerefl fit
* chore(style): authz_api_mnesia style format
feat(stats): track live channel / client count
Track connected client count
In order to correctly display the number of connected clients in our monitor dashboard, we need to track those connections that are actually connected to clients, not considering connections from persistent sessions that are disconnected. Today, the
connections.count that is displayed in the dashboards considers those disconnected persistent sessions as well.
The new statistics can be found in the `emqx_management` plugin, under `/api/v4/stats`, in the keys `live_connections.{max,count}`.
Ported from #6056 .
Track connected client count
In order to correctly display the number of _connected_ clients in our
monitor dashboard, we need to track those connections that are
actually connected to clients, not considering connections from
persistent sessions that are disconnected. Today, the
`connections.count` that is displayed in the dashboards considers
those disconnected persistent sessions as well.
The new statistics can be found in the
[`emqx_management`](https://github.com/emqx/emqx/tree/main-v4.4/apps/emqx_management)
plugin, under `/api/v4/stats`, in the keys
`live_connections.{max,count}`.
A few FVT tests are very flaky when run in rlog core+replicant cluster
configuration (for instance `V5/test_publish.py::test_topic`). We are
disabling this test configuration temporarily while we investigate
further and mitigate it.
test(fvt): extend functional verification tests to use replicant node
This parameterizes the Functional Verification Tests (FVTs) that run
in CI to use a replication log (RLOG) role of "replicant" for one of
the nodes. With this addition, our FVTs may explore more scenarios
with data replication.
For this new cluster configuration, we target only the replicant node
during the tests to avoid race conditions due to replication lag.
there seems to be race conditions related to some tests with sessions
hitting the core and the replicant alternately and rlog.
for intance, if there is some delay in this replication, a new
connection made to the replica with a just-created session in the core
may not have been replicated to the replicant, resulting in a test
failure if it expects the session to be present.
since such replication lags are inherent to the core-replicant
topology, we can try to target only the replicant to avoid seeing this
inconsistent view of the system during the tests.
JimMoen