Extend `ClientMessage::CallReducer` with flag to indicate no reply to caller

[Centril]

So that we can disable this in fn eval_updates:

            if let Some((_, client)) = event
                .caller_address
                .zip(sender_client)
                .filter(|(addr, _)| !eval.contains_key(&(event.caller_identity, *addr)))
            {
                // Caller is not subscribed to any queries,
                // but send a transaction update with an empty subscription update.
                let update = SubscriptionUpdateMessage::default_for_protocol(client.protocol, event.request_id);
                send_to_client(client, &event, update);
            }

[gefjon]

Met w/ Mazdak and John to discuss our customers' specific needs here, and how that affects our user-facing design. Relevant info we determined:

• Our bandwidth-constrained client can divide reducers into two categories: those which should always send a successful ACK with metadata, and those which should never do so. I.e. they do not have a single reducer for which some calls need metadata and others do not.
• However, they do need reducer metadata for certain reducers; the first category is not empty.
• Said client does not care about metadata for other users' calls, or about metadata in transaction updates that contain rows, or about failed reducer NAKs. They are only concerned about successful ACKs which contain 0 subscribed rows.

Combining these constraints, and given our timeline, I suggest:

• Internally, whether to broadcast an empty ACK after a call is encoded as a bit or byte in the WS ClientMessage::CallReducer, and is a property of the individual reducer invocation. This is not currently necessary, but allows us to implement other user-facing designs in the future, and also is easy.
• In the client SDKs, for each reducer defined by a module, the DbConnection exposes a mechanism to disable ACKs for that reducer. Likely we mark this interface "unstable" for now. For now, we offer no way to undo this and re-enable ACKs.
• This configuration is in a separate namespace on the DbConnection, likely ctx.reducer_config, like ctx.reducer_config.my_reducer.disable_empty_success_notification(). Using a separate namespace saves us from having to carve out a reserved chunk of the reducer namespace.
• Whenever the SDK sends a ClientMessage::CallReducer, it checks whether that particular reducer has had its empty success notifications disabled, and includes that flag in the outgoing message.
• If someday we need to expose finer-grained per-call control over the flag, we design a user-facing interface at that time. Frankly I somewhat doubt this will be necessary in the foreseeable future.