CDRIVER-6055 Audit array allocations

[Julia-Garland]

Motivation

"There are several points in the codebase that use bson_malloc(sizeof(T) * N) to allocate arrays of objects. This should not do an in-situ multiplication, since a large value of N will cause integer overflow and result in either an allocation failure or a bogus allocation size. Also, N = 0 can cause issues since malloc(0) is undefined/unspecified."

Summary

Array allocations of the form bson_malloc(sizeof(T) * N) now use a new function bson_array_alloc() which handles multiplication of the two terms internally. Likewise, equivalent calls to 'bson_malloc0(sizeof(T) * N) now usebson_array_alloc0()`.

[vector-of-bool]

Since this is very similar to calloc, I recommend consolidating these into a single new function bson_calloc that uses the calloc function on the BSON vmemtable, rather than adding two new public APIs. This will also defer the calloc logic to the underlying allocator, which may have more smarts based on object size.

[vector-of-bool]

Since the pattern everywhere is almost always (T*)bson_array_alloc(sizeof(T), N), this is a good time to use a function-like macro:

// Plain function
void* _bson_alloc_n_impl(size_t item_size, size_t count);
// Macro that does the right thing every time:
#define bson_alloc_n(Type, Count) \
  ((Type*)_bson_alloc_n_impl(sizeof(Type), (Count))

This also ensures the returned pointer type is correctly used, rather than allowing the implicit-cast from void*.

[Julia-Garland]

Since most of the original function calls I changed were to bson_malloc, not bson_malloc0, would consolidating into a calloc wrapper where memory is always zeroed out be cause for any efficiency concerns?

[kevinAlbs]

I would rather keep a distinct non-zero alloc for cases that are performance sensitive. For example allocations in mongoc-set.c might be arbitrarily large. Maybe add a bson_alloc_n0?