If the rpc in `emqx_dashboard_monitor_api:get_collect/1` fails, an
empty map is return. But the current function expects a 4-tuple,
which results in a 500 error returned on such occasions.
```
curl -su admin:public localhost:8888/api/v5/monitor/current | jq .
{
"code": "INTERNAL_ERROR",
"message": "error, function_clause, [{emqx_dashboard_monitor_api,format_current_metrics,[[#{},{0,0,0,0},{0,0,0,0}],{0,0,0,0}],[{file,\"emqx_dashboard_monitor_api.erl\"},{line,179}]},{emqx_dashboard_monitor_api,current_counters,2,[{file,\"emqx_dashboard_monitor_api.erl\"},{line,167}]},{minirest_handler,apply_callback,3,[{file,\"minirest_handler.erl\"},{line,112}]},{minirest_handler,init,2,[{file,\"minirest_handler.erl\"},{line,38}]},{cowboy_handler,execute,2,[{file,\"cowboy_handler.erl\"},{line,41}]},{cowboy_stream_h,execute,3,[{file,\"cowboy_stream_h.erl\"},{line,318}]},{cowboy_stream_h,request_process,3,[{file,\"cowboy_stream_h.erl\"},{line,302}]},{proc_lib,init_p_do_apply,3,[{file,\"proc_lib.erl\"},{line,226}]}]"
}
```
If an empty username or password are given during the initialization
of `emqx_dashboard_admin`, it'll return just the atom `ok`, which
breaks the expected `{ok, _}` in `emqx_dashboard_app:start/2`.
```
{'EXIT',
{{failed_to_start_app,emqx_dashboard,
{emqx_dashboard,
{bad_return,
{{emqx_dashboard_app,start,[normal,[]]},
{'EXIT',
{{badmatch,ok},
[{emqx_dashboard_app,start,2,
[{file,
"/home/thales/dev/emqx/emqx/apps/emqx_dashboard/src/emqx_dashboard_app.erl"},
{line,32}]},
{application_master,start_it_old,4,
[{file,"application_master.erl"},{line,293}]}]}}}}}}}}
```
Deleted the wrapping union.
i.e. previously it's
union([union([...]), array(union([...]))]).
not it's
array(union([...]))
It is after-all a lazy type, and the dynamic check allows
single-elemented arrays not to have `[]` around it.
the old union of array of union schema was just adding confusion
Port from #6406 to 5.0.
When multiple clients try to connect concurrently using the same
client ID, they all call `emqx_channel:ensure_connected`, increasing
the live connection count, but only one will successfully acquire the
lock for that client ID. This means that all other clients that
increased the live connection count will not get to call neither
`emqx_channel:ensure_disconnected` nor be monitored for `DOWN`
messages, effectively causing a count leak.
By moving the increment to `emqx_cm:register_channel`, which is only
called inside the lock, we can remove this leakage.
Also, during the handling of `DOWN` messages, we now iterate over all
channel PIDs returned by `eqmx_misc:drain_down`, since it could be
that one or more PIDs are not contained in the `pmon` state.
