FDCAN peripheral was not performing as expected, so I debugged and tested it.

Original code where this was based on used a independent state with regards to the interrupt. During heavy bus error conditions the internal state could become out-of-sync with the interrupts.

Testing on NucleoG474 and using PR #6911 (which is not yet merged..) but checked the HAL function to work with H7 family

More explanation:
During the development of an application using the CAN communication, we found a interrupt-run-away in some situations. We found that the error interrupt triggered (al be it Warning, Passive or Bus-Off, all triggered it) the run-away. We could not get out of the non-responsive state without a reset.

I checked the code, and found two things: the error interrupt is enabled but not cleared in the interrupt routine, and an internal variable 'State' that was used to track the message received state (empty, new, full, overflow) that was not directly related to interrupt that indicated the state.

In this pull request I fixed these issue by adding more values for the interrupt reason (warning, passive, bus off) and clearing the error interrupts, and making the internal state directly dependent on the interrupt state for received messages.

While testing the fixes I also found that introducing the FIFO1 in the CAN receive stage, another issue existed. Even if the messages are received into the FIFO1 (by selecting message filtering for FIFO0 and FIFO1), the interrupt firing was indicating FIFO0 Rx. The configuration of the interrupts for this is now also fixed. The CAN peripheral has 2 interrupt lines going into the NVIC controller. The assignment of the interrupt reasons to these 2 interrupt lines was missing. Now the reception of FIFO1 messages, triggers the 2nd interrupt line. Other interrupts (Rx FIFO0 and Bus Error) are assigned to the 1st interrupt line.