Split an Engine struct from the existing Server struct.

[EwenQuim]

As you know, I'm working on other frameworks integration. I thought that splitting the OpenAPI struct would be enough but it isn't.

I currently am re-writing some bits of Fuego's error handling for Gin but I think I shouldn't.

I think we need to split Server (again!) to be able to plug more easily new Frameworks.

This will allow to re-code the bare minimum when creating bindings for other routers!!! We will be able to plug any router and also keep Fuego's philosophy as per #263.

---

Of course :

• Changes can, and thus, will be backward-compatible
• As multiple changes are needed, I'll be making several PRs
• We'll try not to impact performance (we need benchmarks)
• I'm waiting for your approval as it is a significant change

[EwenQuim]

@dylanhitt @ccoVeille @rizerkrof

[dylanhitt]

FYI plan to read this maybe tomorrow or Saturday morning. Day job is getting in the way this week.

[dylanhitt]

I currently am re-writing some bits of Fuego's error handling for Gin but I think I shouldn't

I don't think we should be opinionated on what other frameworks do. We'd easily end up withe N+1 problem where we'd need to implement things per framework, "Engine", we want to plug in.

For instance #293 I was thinking about how this could interact with gin/echo and came to the conclusion it just wouldn't also the users coming from those communities probably have a logger they adore why fight it.

I really like this

[EwenQuim]

Yeah we have to remember to stick mostly to net/http. Fuego core identity is the Server.

I see gin/echo compatibility (the Engine) like a nice "plus" to help people migrate or try core Fuego functionalities. If they keep their router, they won't get all of the nice feature we crafted around the stdlib. But they will get enough (mostly, the OpenAPI part) so they find value in trying the lib :)

[EwenQuim]

Fixed in #290