Ok, there are two general problems with this thing:

1. This contains various weird changes for packet filter, it doesn't look like related to the topic.
2. As SRT is a library, manual - or lazy at worst - calls of the startup is necessary due to the problems of the global constructor call order in C++.

C++ guarantees the order of initialization only within the frames of one source file, but not between files, and this actually causes problems if you provide a library (meaning, global constructors for objects provided by the application may be called prior to those provided by the library). A potential risk exists, for example, if some application is going to create a socket in one of its global constructors. We can blame the application, if the caller hasn't called srt_startup() in the beginning (although this should be cleared off by the lazy initialization at the first socket), but that's exactly why the CUDTUnited uses one if the singleton implementation.

Thank you for your feedback! Here’s my response to both points:

• Packet Filter Changes:
  I understand that the packet filter modifications might seem unrelated to the main topic of this pull request. However, they were introduced to address the "Static Initialization Order Fiasco," which directly relates to concerns about global constructor call order. By separating the packet filter factory from CUDTUnited, we mitigate the risk of undefined behavior caused by initialization order issues.
• Startup Handling in a Library Context:
  I’ve reverted the global instance back to a singleton as suggested, so we should now be aligned on this point. The call to startup() and cleanup() can now be either manual or lazy, which ensures correct initialization and resolves issue [BUG] Regression with commit bc2f48e057644ab9  #3098.

Alright, then I understand that this first change can be added independently on the second one, so this one better go to the other PR. That would be cleaner.

I’ve decided not to create a separate pull request for the packet filter changes. These modifications are not entirely independent, as they rely on the existing codebase, which means the pull requests would need to be applied in a specific order. Additionally, the updates to the packet filter are justified within the context of the overall changes in this pull request.

Regarding the packet filter changes, I’ve simply encapsulated the global variables (filters and builtin_filters) into PacketFilterFactory.

This allows us to:

• Use them within a PacketFilterFactory singleton.
• Initialize the singleton via its constructor instead of calling the static globalInit() method from startup(), which was causing the Static Initialization Order Fiasco (SIOF).

My latest push aligns srt_startup() with the documentation, ensuring that the garbage collector thread starts as soon as srt_startup() is called, rather than being delayed until the first socket is created.

In the end, this pull request maintains the same overall logic as before, with the key difference that it now correctly fixes issue #3098.