Port of #7108 .
Sometimes, the `emqx_sys_mon:procinfo/1` might be called with
something that is not a port, like `[]`. Not sure on the conditions
for this to happen.
```
2022-02-18T20:05:02.671592+00:00 [error] Generic server emqx_sys_mon terminating. Reason: {badarg,[{erlang,port_info,[[]],[{error_info,#{module => erl_erts_errors}}]},{emqx_sys_mon,portinfo,1,[{file,"/emqx/apps/emqx/src/emqx_sys_mon.erl"},{line,205}]},{emqx_sys_mon,'-handle_info/2-fun-5-',2,[{file,"/emqx/apps/emqx/src/emqx_sys_mon.erl"},{line,150}]},{emqx_sys_mon,suppress,3,[{file,"/emqx/apps/emqx/src/emqx_sys_mon.erl"},{line,184}]},{gen_server,try_dispatch,4,[{file,"gen_server.erl"},{line,695}]},{gen_server,handle_msg,6,[{file,"gen_server.erl"},{line,771}]},{proc_lib,wake_up,3,[{file,"proc_lib.erl"},{line,236}]}]}. Last message: {monitor,<0.7796.0>,busy_dist_port,[]}. State: #{events => [{busy_dist_port,#Port<0.127>}],timer => #Ref<0.2758388682.1853620226.133920>}.
```
Without passing an empty argument list to `emqx_ctl:print`, formatting
instructions like `~n` are being printed literally.
```
Ignore.~nJoin the cluster successfully.~nCluster status: #{running_nodes =>
['emqx@emqx-0.int.thalesmg','emqx@emqx-1.int.thalesmg',
'emqx@emqx-2.int.thalesmg','emqx@emqx-3.int.thalesmg',
'emqx@emqx-4.int.thalesmg'],
stopped_nodes => []}
```
As described in the 5.0 specification, we should disconnect clients that
exceed the receive-maximum limit.
> If it receives more than Receive Maximum QoS 1 and QoS 2 PUBLISH packets
where it has not sent a PUBACK or PUBCOMP in response, **the Server uses a
DISCONNECT packet with Reason Code 0x9**
fix: #6447
(Same as #6289 )
This adds the information from `proc_lib:initial_call/1` and the
current stacktrace from the process info to `emqx_sys_mon:procinfo/1`
to aid in debugging some warnings with no context such as the
following:
```
2021-11-23T12:33:59.387818+00:00 [warning] info: [{old_heap_block_size,45988046},{heap_block_size,22177879},{mbuf_size,0},{stack_size,40},{old_heap_size,22354134},{heap_size,7106339}], line: 130, mfa: emqx_sys_mon:handle_info/2, msg: large_heap, procinfo: [{pid,<0.2667.0>},{memory,579763664},{total_heap_size,68510672},{heap_size,22177879},{stack_size,40},{min_heap_size,233},{initial_call,{proc_lib,init_p,5}},{current_function,{gen,do_call,4}},{registered_name,[]},{status,running},{message_queue_len,360945},{group_leader,<0.1660.0>},{priority,normal},{trap_exit,false},{reductions,16493271},{last_calls,false},{catchlevel,4},{trace,0},{suspending,[]},{sequential_trace_token,[]},{error_handler,error_handler}]
```
Prior to this fix, 'kick' and 'discard' calls may timeout (or
fail for other reason), failures lead to only a log, then
continue to allow the new session to get registered.
As a result, in case a client is stuck, there is no way to
force it to step down, end up with multiple connections (sessions)
for the client ID in dashboard.
After this fix, the stale pids are notified to shutdown
via a gen_server:call, and forced with a exit(Pid, kill) for any
exception happend to the gen_server:call
Prior to this commit, there was a bug in emqx_frame:split/2
the tail number of bytes was used for header number of bytes
whens split. As a result, if the tail happens to be longer
then haeder, the parsing state becomes invalid and it crashes
when the next packet arrives
The split was a over-engineered micro-optimization, so it
has been deleted instead of fixed
Prior to this change, plugin config files are only allowed
to be placed in the collective config dir etc/plugins.
In order to support external plugin's drop-in deployment,
this commit made emqx_plugins module to read conf file
in application's etc dir
JianBo He