SpfServer leaks the SPF_server_t object allocated in SpfServer_construct

[rrendec]

The leak was identified by valgrind.

==51677== 2,572 (56 direct, 2,516 indirect) bytes in 1 blocks are definitely lost in loss record 803 of 821
==51677==    at 0x4C38185: malloc (vg_replace_malloc.c:442)
==51677==    by 0x4E5D256: SPF_server_new (in /usr/lib64/libspf2.so.2.1.0)
==51677==    by 0x40BAF0: SpfServer_construct (mod_spf.c:18)
==51677==    by 0x527DCC0: duk__handle_call_raw (in /usr/lib64/libduktape.so.202.20200)
==51677==    by 0x5278649: duk__js_execute_bytecode_inner.isra.113 (in /usr/lib64/libduktape.so.202.20200)
==51677==    by 0x527CD2E: duk_js_execute_bytecode (in /usr/lib64/libduktape.so.202.20200)
==51677==    by 0x527DC82: duk__handle_call_raw (in /usr/lib64/libduktape.so.202.20200)
==51677==    by 0x529660D: duk__pcall_prop_raw (in /usr/lib64/libduktape.so.202.20200)
==51677==    by 0x527F6A7: duk_handle_safe_call (in /usr/lib64/libduktape.so.202.20200)
==51677==    by 0x52802DB: duk_pcall_prop (in /usr/lib64/libduktape.so.202.20200)
==51677==    by 0x405649: call_js_handler (smtp_server.c:340)
==51677==    by 0x40697E: smtp_hdlr_data (smtp_server.c:976)

The SPF_server_t object is supposed to be released in SpfServer_finalize() but further debugging shows that the finalizer is not called. Tested in debug mode (-d on the command line) and with the while() condition at the end of main() changed to 0. According to the documentation, duk_destroy_heap() is supposed to finalize all remaining objects, so even if the SpfServer instance is not garbage collected earlier, the finalizer should eventually be called through duk_destroy_heap().

Tested on EL8 (Alma) with duktape-2.2.0-6.el8.x86_64.