Ok I am taking a stab at the issue, because I am in exactly the same situation.
Engine vs. Libraries
This is one thing I often come across. Sure when you build a game you need an "engine". And many novice developer will look at the Quakes and Unreals and think that a engine is a monolithic piece of software that is multiple of millions lines of code. But these engines come from large companies and large companies tend to build large systems.
Over the years I have found that when I write a library that does exactly one task and knows nothing about an "engine" as the most useful. The reason is because the library can be used in any context. Years later I tend to reuse a library unaltered from a previous project, but any code that was in the Engine is basically impossible to extract.
It may be sensible to build libraries (or use third party libraries) that solve one task and then integrate them into an "engine". The engine is then only glue between the bits and serves to implement a consistent handling and the almighty
Simulation vs. Presentation
It makes sense to think about simulation (i.e. game logic) and presentation (rendering, sound), before asking about client and server. The reason being, that the server needs only to handle simulation, but the client needs to handle simulation (for local prediction) and presentation. You don't want to have code for visual effects running on the server, just because you think the physics are only done on the server.
It makes sense to package the engine into a central library or multiple libraries and have the client and server link that, since they are going to share much code. But you want to keep is somewhat modular, so you do not need to install presentation bits on a dedicated server setup. (But you can get away with it though.)
Ok this is my current approach and it works quite well, but it is my approach and may not fit your needs.
The meat of my engine is implemented in libraries that are fully independent from the engine. I use some common libraries such as ODE for features that are fully realized by other people.
The engine is structured in the way that you have a central Engine class, but that does nothing meaningful. It is extended by Services, each service doing one special task, such as rendering or physics simulation. The systems are actually encapsulating a library. Entities, that are very specific to the actual game then use the systems to do anything non trivial. The important bit here is that, entities are expected to properly behave in the absence of a service. This enables one code stack to live in the server, client and editor.
The code is then separated in a base module that defines the basics, such as the Engine, Service and Entity base cases. Each service then lives in it's own module. The client and server then only load and link against the services they actually require.
I implemented the editor as a optional service in the client, that is loaded on demand when a specific command line argument is set. But this is a matter of taste and it clearly could be done as separate executable or the Engine class ditched completely and only the entities used directly.