asset.hold_request sms_check constraint can be usurped by orphaned sms_carrier data

Hold requests in asset.hold_request have a constraint called "sms_check" that makes sure that all records that have a sms_notify value also have a sms_carrier (id) value, as both these fields are needed in order for an SMS notification be sent successfully.

However, I have encountered that existing holds can be updated such that sms_notify is cleared/blanked but the sms_carrier (ID) remains, leaving the hold(s) with an orphan carrier id, that can later usurp the sms_check validation during subsequent updates.

For example, a user may update a hold's sms_notify phone number that has an orphan sms_carrier value, but forgets to set the proper carrier, thus later causing failure to notify.

I propose we discuss the possibility of a database BEFORE trigger being added, so that we may prevent rows with "orphan" sms_carrier fields.