mlxbf_gige: dont log RX errors by default

[David Thompson]

SRU Justification:

[Impact]

During certain reset flows, the BF3 kernel log shows instances of this MAC receive error:
  mlxbf_gige MLNXBF17:00: rx_mac_error tx_ci=0x0 tx_pi=0x0 rx_ci=0x1 rx_pi=0x80 int_mask=0x1
This log shows that a packet was received with a MAC error, and this packet was dropped.
While everything is handled OK, this event should not be placed into dmesg log by default.

[Fix]

The initial "enable" value of the mlxbf_gige msglvl infrastructure logic
includes the value for NETIF_MSG_RX_ERR. The fix is to change the initial
value, removing NETIF_MSG_RX_ERR, and preventing any logging based on this
type of RX error. Instead, the driver has a counter tracking this type of
RX error and its value can be displayed via "ethtool -S oob_net0"

[Test Case]

* Exercise reboot, power cycle, and FW reset flows of BF3
* Verify no instances of "rx_mac_error" log entries in the dmesg output

[Regression Potential]

None

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

This bug is awaiting verification that the linux-bluefield/5.15.0-1084.86 kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-jammy-linux-bluefield' to 'verification-done-jammy-linux-bluefield'. If the problem still exists, change the tag 'verification-needed-jammy-linux-bluefield' to 'verification-failed-jammy-linux-bluefield'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!