Diesel queries: should we prefer `is_not_distinct_from()` over separate `eq()` / `is_null()` branches?

(This is followup from #9570 where we added additional branching queries.)

When we compare a nullable column against a Rust value with the type Option<T>, we often box the query and branch based on its value to either compare with eq or check for is_null; e.g. from main:

https://github.com/oxidecomputer/omicron/blob/4c9d4a0df27588128da233f02004d0b7356ef44d/nexus/db-queries/src/db/datastore/bgp.rs#L109-L122

This is because eq() faithfully reproduces the SQL behavior of some_column = NULL returning false even if the value of some_column is itself NULL.

However, I believe we could replace these branches by using https://docs.rs/diesel/latest/diesel/expression_methods/trait.PgExpressionMethods.html#method.is_not_distinct_from, which behaves more like we'd expect from Option comparisons in Rust:

This behaves identically to the = operator, except that NULL is treated as a normal value.

The value of this is pretty small on examples like the above (although we potentially get to drop the boxing of the query to type-erase it); it becomes more of a win if the branching contains multiple other filters that have to be manually kept in sync. An example from #9570, where these branches are identical except for addr.eq(addr) vs addr.is_null():

https://github.com/oxidecomputer/omicron/blob/2a5ffb0cdfd523f4cf080afa92b48b0be217e1bc/nexus/db-queries/src/db/datastore/bgp.rs#L891-L910

Read the nullable-value branches in nexus/db-queries/src/db/datastore/bgp.rs at lines 109-122 and 891-910, along with follow-up issue #9570. Compare the existing eq()/is_null() behavior with Diesel's PgExpressionMethods::is_not_distinct_from, then determine whether the approach should replace these patterns and document the affected scope and validation needed.