Fix minor memory leak

[val-ms]

The memory allocated for certs_directory in the ClamAV engine is not free'd when the engine is free'd. This isn't readily apparent when using a mempool because the mempool itself is free'd and the issue is masked.

Also: I found that the location in cl_engine_free() where we estimate the number of tasks incorrectly placed the fuzzy_hashmap free task in the block where we free the test_root, rather than up in the engine->root for-loop. Fixed.

Edit: I have also added a fix for a leak when multiple idb signatures are loaded. I discovered this while trying to come up with simple repro steps for anyone wishing to manually test this fix.

Repro steps on Linux, not Mac (requires valgrind):

1. Build clamav with the cmake option -D DISABLE_MPOOL=ON

2. Run ctest -V

[jhumlick]

I'm just curious as to why the change from unsigned int, which is almost always 32-bits, to uint32_t was made. Should I make similar changes when I edit older code?

[val-ms]

The lengths of older C types, such as char, short, int, long, vary by OS and arch. int is more reliably 32-bits than long, but both may vary by OS and architecture: https://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models

I habitually switch unsigned, int, and long types to stdint.h types like uint32_t and uint64_t. For data, uint8_t is better than unsigned char. For strings, char is fine. int8_t might technically be better to represent data underlying utf8. utf8 is hard in C, and ClamAV code generally does a bad job with it.

Weirdly enough, off_t is also poorly defined. It's still everywhere and ought to be replaced with ssize_t if negative values need to be supported, or size_t otherwise. Most clamav offsets are relative to the start of the file so negative is almost never required. Disclaimer: I've introduced bugs by converting types like this from signed to unsigned, so you have to be really careful when doing that.

On that topic, sentinel values for indicating an error are a code smell. Ideally we'd never use them and would always return an error code (e.g. using cl_error_t) and then pass the back values through function parameters. It's just considerable effort to rewrite to do it that way with existing code, and there is risk we'd introduce a bug by switching.