split out non-HTTP server parts

[arnej27959]

To allow re-use of parts of the HTTP server code, this PR splits the code into generic parts in server.hpp and utils.hpp,
and HTTP-only parts in http-utils.hpp and server.cpp.
Note that even if the diff is large, no code is changed at all, it's just moved to differerent files.

[ericcurtin]

While I agree with the sentiment server.cpp should be split up, I think we should have multiple headers and .cpp files rather than just putting everything in a header

[arnej27959]

While I agree with the sentiment server.cpp should be split up, I think we should have multiple headers and .cpp files rather than just putting everything in a header
I very much agree, and if you look at my earlier attempt in #14331 I had the skeleton ready to work in that direction. But it didn't get any feedback from the maintainers , so this time I'm trying to take a smaller step first.
I'm definitely not going to do any work in splitting it into multiple headers and cpp files without a clear indication that the work won't be totally ignored.

[ngxson]

In most cases it's an anti-pattern to have a huge .hpp file. The ultimate goal is to split the server logic into multiple .cpp files, much like how the libllama or libcommon is structured.

What is more interesting for now is to compile the server into a shared library (instead of being a huge .hpp as you're doing), and expose the HTTP-related things as an interface.

[arnej27959]

Again, I very much agree - moving the code to a separate library with an API should be the goal. In my previous PR I setup the skeleton for such a library (tentatively named server-core), so I could include that part again in this PR if you wish. That would still leave all the code in one big .hpp file of course, but afterwards it would be possible to move parts defining an API into .h files, and implementation into .cpp files. Such splitting would be a series of small commits that should be possible to review.
Another alternative is to just add the skeleton without any code, and move parts of the API there directly in chunks, but that makes it impossible to take advantage of the split before everything is done, so it doesn't help me with my immediate task that requires a split.