Relaxing `Default` trait bound in dogs^3.

Delta query operators (propose, count, validate) require key (and in case of validate value) to implement Default. This innocuous type bound is making life complicated in my use case (ddlog), so I was wondering if there is a way to relax it or introduce a lower-level API that does not require these bounds and instead takes user-provided values for supplied_key values.

The problem is that in order to speed up compilation we recently switched to using dynamic dispatch, where all DD relations store values of the same type that happen to contain a vtable that points to type-specific implementations of comparison, hashing, and other methods. We use some other tweaks to reduce the performance impact of this (like avoiding dynamic memory allocation for small values by storing them inline). Trouble is, I cannot easily add a Default implementation to this type in a meaningful way: each relation stores its own type and there is no single value that acts as a common default for all relations. There are of course ways around this, but all the ones I can think of involve lots of complexity and a potential performance hit.

Thanks!

Start by tracing the delta query operators propose, count, and validate, focusing on where their Default bounds are required. Determine whether those operators can accept user-provided supplied_key values without the bounds; done means the requested lower-level path is defined and covered by appropriate tests.