System becomes unresponsive or crash due to frequent filter changes in a scale scenario having mib2d process in use

This issue might be seen if the following conditions are met:
* On Junos OS platforms
* Scale scenario (filters associated to ~1k IFLs and each filter has > 250 terms ) + Frequent filter changes (all 1k filters are changed every 2-3 mins)
* Process mib2d is used

When a firewall filter is applied to approximately 1k (1000) ifls, each filter containing more than 250 terms, and the filer is updated every 2-3 minutes, the mib2d 
(Management Information Base II Daemon) process monitors these filter changes and collects statistics on every firewall filter change.

The kernel gathers statistics from various Packet Forwarding Engines (PFEs), aggregates them, and sends them via a socket to mib2d, temporarily storing them in mbufs. 
Due to the high frequency of filter updates, mib2d becomes overwhelmed and cannot keep up with reading the statistics from the socket.

As a result, if the socket is not read in time, the system logs the error:
"kernel: failed in writing to socket buffer full"

The entries (mbufs) that overflow the socket are not released, causing an mbuf leak. If this issue continues or repeats, the system may eventually become unresponsive (enter a hang state) or crash, 
generating a VMcore dump, which results in service disruption.

This issue is relevant to both IPv4 Internet Protocol version 4) and IPv6 (Internet Protocol version 6) filter types.

To monitor mbuf usage and detect potential issues, run the following CLI command at regular intervals:
user@device> show system buffers

Workaround:
Disable mib2d process "set system processes mib-process disable" (disabling the mib2b process, SNMP wont work) and use Telemetry to fetch the stats instead of mib2d process.

The issue is addressed via the below PR:

https://prsearch.juniper.net/problemreport/PR1872347