Fix unconditional access of unmocked mongoc_auto_encryption_opts_t fields

[eramongodb]

Followup to #1559, #1565, and #1566. In the end, the issue was indeed undefined behavior, not a codegen bug. The "bypass_auto_encryption" and "bypass_query_analysis" fields are not optional fields, instead defaulting to false. These fields are unconditionally assigned to the mongoc_auto_encryption_opts_t object by the v1 API here, whereas in the v_noabi API, the object was only assigned when true. This is not an observable difference to end users, but it is very important for mock tests. The consequence is that when a v1::client or v1::pool object is constructed with auto encryption opts, the unmocked mongoc setter functions were unconditionally invoked, thus accessing a non-existent object intended only for identity comparison, leading to stack variable out-of-bounds access. I suspect sanitizers did not catch this due to being invalid stack memory access, which they're not very good at diagnosing compared to other scenarios. This would result in the corruption of an unrelated but adjacent object such as one of the mock instances (opts_id, opts_destroy, etc.) or, in the other direction, one of the client_mocks_type data members, hence the segfaults on scope exit (destruction of a corrupted object). "Only on RHEL 8 ARM64" was probably due to stack variable layout determining which object is corrupted and how (circumstantially benign on most other platforms being tested). Rather than requiring mocks of unconditional fields, this PR proposing restoring the old behavior of only invoking the setter for true values.

[kevinAlbs]

Nice catch and analysis. LGTM