kern_intr: Check for NULL event in intr_destroy()

[mhorne]

Summary

It likely won't happen, but is consistent with the other functions of
this KPI.

[ehem_freebsd_m5p.com]

Alas this came to my attention way to late to address on-time. Callers of intr_event_destroy() want to know whether everything has been appropriately released or not. If the event is NULL this likely something failed very early during setup. In such case the event doesn't need to be released since it was never allocated. As such 0 should be the return instead.

The other case is the current INTRNG where due to lazy allocation the event may or may not have been allocated by the time it is time to release. In such case if intr_event_destroy() is going to detect NULL then it simplifies callers to allow passing a pointer with unknown state.

Due to this D38602 now exists.

The actual situation is there are very few callers of intr_event_destroy(). Most calls assume it will succeed and fail to check the return. The likely course of action for many callers on error is to leak the pointer since there is no provision to cope with a failed release. If one is lucky printf() might be called.