Drop glib like it's hot

[ikeydoherty]

Just the mere use of GLib is enough to cause cve-check-tool to leak.

We removed 90% of the old glib code, but it's starting to creep back.

Certain points to note:

• More recent glib/gio configurations try and load modules dynamically, resulting in cve-check-tool leaking through a dconf connection it didn't use or ask for (unacceptable)
• GSLIst/GList cause leaks through the new GLib private API usage
• Static initialisation code in GLib is never ever cleaned.
• "Portable" has a high cost. This is a C99 tool that isn't going to ever target Windows (out of scope. Why are you use git/source packages on Windows anyway?)

So, nuke it.

Worklist:

• [x] Provide replacement iterable HashTable/Hashmap
• [ ] Provide replacement linked list
• [ ] Replace all list/hashtable usage to the new library API
• [x] Kill all g_build_path type functions, we don't require this "portability"
• [ ] Decompress files natively, zlib is there for a reason
• [ ] Stop linking core to glib and then fix the fallout (gchar, g* types.)
• [ ] Remove GDateTime*
• [x] Find methods to either disable interaction with glib in JIRA plugin, or split it off into a .so to prevent anything else from linking to glib. Probably counts as an OUTPUT plugin now anyway. (being reworked)

[ikeydoherty]

As we can see here, GLib has all the integrity of a modern day lawyer:

==14924== 24 bytes in 1 blocks are possibly lost in loss record 800 of 1,993
==14924==    at 0x4C2D118: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==14924==    by 0x5C4BF40: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.4600.1)
==14924==    by 0x59DA815: g_type_class_ref (in /usr/lib64/libgobject-2.0.so.0.4600.1)
==14924==    by 0x59DA28C: g_type_class_ref (in /usr/lib64/libgobject-2.0.so.0.4600.1)
==14924==    by 0x59C9587: g_param_spec_flags (in /usr/lib64/libgobject-2.0.so.0.4600.1)
==14924==    by 0x5708815: ??? (in /usr/lib64/libgio-2.0.so.0.4600.1)
==14924==    by 0x59DA68C: g_type_class_ref (in /usr/lib64/libgobject-2.0.so.0.4600.1)
==14924==    by 0x59DA28C: g_type_class_ref (in /usr/lib64/libgobject-2.0.so.0.4600.1)
==14924==    by 0x59C17E3: g_object_new_valist (in /usr/lib64/libgobject-2.0.so.0.4600.1)
==14924==    by 0x568744D: g_initable_new_valist (in /usr/lib64/libgio-2.0.so.0.4600.1)
==14924==    by 0x5687515: g_initable_new (in /usr/lib64/libgio-2.0.so.0.4600.1)
==14924==    by 0x98D7E4D: gvfs_dbus_daemon_proxy_new_for_bus_sync (in /usr/lib64/gvfs/libgvfscommon.so)
==14924==    by 0x9D15788: ??? (in /usr/lib64/gio/modules/libgioremote-volume-monitor.so)
==14924==    by 0x5689975: ??? (in /usr/lib64/libgio-2.0.so.0.4600.1)
==14924==    by 0x59E0B00: g_type_module_use (in /usr/lib64/libgobject-2.0.so.0.4600.1)
==14924==    by 0x568A147: g_io_modules_scan_all_in_directory_with_scope (in /usr/lib64/libgio-2.0.so.0.4600.1)
==14924==    by 0x568A491: ??? (in /usr/lib64/libgio-2.0.so.0.4600.1)
==14924==    by 0x568AAE1: ??? (in /usr/lib64/libgio-2.0.so.0.4600.1)
==14924==    by 0x567742D: g_file_new_for_path (in /usr/lib64/libgio-2.0.so.0.4600.1)
==14924==    by 0x40237C: load_cve_mapping (util.c:169)
==14924==    by 0x402599: cve_mapping_test (check-packaging.c:210)
==14924==    by 0x62199C7: srunner_run (in /usr/lib64/libcheck.so.0.0.0)
==14924==    by 0x403A3B: main (check-packaging.c:253)

[ikeydoherty]

We'll now handle this properly in branch 2

[ikeydoherty]

Implemented in branch 2