[BUG] stir/shaken MI reload commands for CA/CRL are broken

[vasilevalex]

OpenSIPS version you are running
All versions with stir_shaken module.

Describe the bug
The stir_shaken_ca_reload and stir_shaken_crl_reload MI commands have several issues, but they are all minor with an architectural problem: the X509_STORE *store is a process-local global variable. MI commands execute in the attendant process, so any reload only updates the store in that process. Worker processes keep using the store initialized during mod_init() and never see any changes. The reload MI commands are useless.

Beyond that, the reload functions themselves have additional bugs:

1. stir_shaken_ca_reload requires both ca_list AND ca_dir. If only one is configured, the reload fails. The init function (init_cert_validation) correctly accepts either one (if (ca_list || ca_dir)). The same applies to stir_shaken_crl_reload requiring both crl_list and crl_dir.
2. stir_shaken_crl_reload destroys the CA store. init_cert_crl_reload() creates a brand-new X509_STORE and only loads CRLs into it, all previously loaded CA certificates are lost. After a CRL reload, certificate verification would fail because no CAs are trusted. The same issue exists in the CA reload path: it drops CRL configuration.
3. Memory leak on reload. Both reload functions assign a new X509_STORE to store without calling X509_STORE_free() on the old store.
4. System CA bundle is always loaded, with no way to disable it. Both init_cert_validation and init_cert_ca_reload unconditionally call ss_store_set_default_paths(), which loads the OS-provided CA bundle. If an operator wants to trust only specific STIR/SHAKEN CAs (e.g., from the STI-PA), there is no way to prevent the system CAs from also being trusted. Standard system CAs can't be used to sign STIR/SHAKEN certificates, so this makes no sense.

To Reproduce

1. Start OpenSIPS
2. Issue "mi stir_shaken_ca_reload" or "mi stir_shaken_crl_reload"
3. Nothing happens

Expected behavior
The MI reload functionality needs to be redesigned. The store must either live in shared memory or a reload-signaling mechanism must be used so that each worker process rebuilds its own store. Additionally, reload should preserve the full configuration (CAs + CRLs together), the ca_list/ca_dir requirement should match init behavior, and I think the system default CA bundle should never be loaded.