CMake build system refactor

[xorrvin]

Hi ZeroTier community,

First of all, thanks for the amazing project! ZeroTier makes global connectivity so much easier and convenient.

I have been skimming through the code and found few potential ideas for build system improvement, which I'd like to introduce through this discussion. I believe most (if not all of them) are solvable via complete CMake migration.

While current Makefile-based build system is bulletproof in terms of platform support, CMake is modern and ubiquitous enough to be well supported everywhere. Esoteric targets like Synology and friends are built in the Docker containers anyway, so I see no problem here. There's initial CMake support already and I have seen multiple issues mentioning it, so I assume it can be a step in the right direction.

So what's are the issues which CMake can solve "for free"?

• Vendored deps. While it's a WIP (I believe) since for example miniupnp is already handled, stuff like http_parser json and redis are hardcoded and quite trivial to solve, either git submodules or native CMake's FetchContent can be used. CMake also provides a tooling for enforcing versions of the dependencies, which should make overall build experience more straightforward. Currently certain distributions (like Gentoo) do it manually: https://github.com/gentoo/gentoo/blob/5872780b41c9698143265b649620bc1af484efe3/net-misc/zerotier/zerotier-1.16.0.ebuild#L89
• Code duplication. Current Makefile build system contains pieces of duplicated code, especially related to the architecture support, and makes some obscure assumptions regarding CFLAGS, which are not propagated universally. For example: https://github.com/zerotier/ZeroTierOne/blob/dev/make-bsd.mk#L124 this won't work properly on a raspberry pi 4, because its CPU doesn't have support for the crypto extensions, later in the same file it would outright fail on an unknown architecture (instead of using generic unoptimized crypto path); https://github.com/zerotier/ZeroTierOne/blob/dev/make-mac.mk#L92 Mac/iOS version gets unconditional LTO, while Linux/BSD do not (why?) and so on.
• More universal crypto support. As previously mentioned, a default (non-simd) crypto path would allow even broader platform support, but current Makefile build system doesn't support it. Additionally, some lightweight external crypto library can be used to boost desktop performance, and fallback to the vendored crypto otherwise. I believe that's another benefit of unvendoring.
• Build unification. Currently there's no easy way to build all targets on all systems with a particular set of CFLAGS or ASANs, as the support is spotty and scattered across multiple files.
• Windows support. The same CMake file can be used to produce Windows DLL, instead of relying on .sln exclusively (code duplication again).

Please let me know what you think!

Thank you.