Chore add api interfaces, phase3

[NagyZoltanPeter]

Description

Based on the proposed shape of APIs from #3974
This PR suggest to introduce interface definitions for all three api layers.

The benefit that it adds, easier read what is intended to be public really and user/dev facing of any layers.
This also allows us to extract types, structures, and definitions into the highest level that represent the data layer of our APIs.

Changes

IKernel, IMessagingClient and IRealiableChannelManager abstract classes added at logose_delivery/api/

Issue

closes #

[github-actions]

You can find the image built from this PR at

quay.io/wakuorg/nwaku-pr:3975

Built from 1c3e5c1

[Ivansete-status]

Thanks for the PR!
I really think we can simplify the approach. Defining the interfaces this way adds a layer of indirection that the solution doesn't really need. We can instead have each layer define its own concrete API modules directly. That keeps the design simpler.

[NagyZoltanPeter]

Thanks for the PR! I really think we can simplify the approach. Defining the interfaces this way adds a layer of indirection that the solution doesn't really need. We can instead have each layer define its own concrete API modules directly. That keeps the design simpler.

I think having such indirection can help keep API clean. Detaching from the implementation files helps easier understanding the flow because the reader should not go through implementation details unless he/she wants to.
I'm just advocating the having interface class articulates our intent as lib developers.
I know it looks just semantic, but helps us in long term with its constraint what you can do and what should not.
Also by leveling surfacing types out of implementation also gives us cleaner dependencies in the lower layers.

[fcecin]

We need some sort of facade solution to major library boundaries (layers are equivalent to independent libraries -- that's why we call them layers). We should not expose function someApiName { lotsOfLinesOfLogicHere } in a single file.

We already suffered this before: directories, files, procs, structures named "API" that are not "I" at all, they carry implementation logic, that is not split between the "API" (not) folder and the thing it is dispatching to. And then it starts growing the "local" dispatch logic.

The nice thing about proper interfaces (however they are implemented) is that they read as lists of things you can do, without interspersing the names of the things you can call with a bunch of irrelevant stuff that doesn't even solve the whole problem (all they do is force your logic to be split in at least two places for no reason). In C++ that would be an "interface" header file where all the "dispatch" methods are inlined; we don't do that.

If we don't go with the tried-and-true ISomething / Something Java/OOP classic here:

• The bare minimum is that we need some strict discipline on top of "list of flat procs." E.g. each proc is only allowed to have one line in the implementation, which is to delegate to some static (never nil) internal component. No if pointer not nil, if lifetime state, if config equals. Just call something else.
• I would vote against "manual" function tables, since that just restates what is proposed here in this PR, and by nim-brokers (POC: structured api interface  #3946 / Separate core (Waku) and MessagingClient using nim-brokers #3904) for that matter.
• Nim concepts could do it, but to speedrun this now doesn't fit the risk tolerance profile/pattern we are already displaying against the other stuff we tried so my guess would be that we don't want this now.

[NagyZoltanPeter]

Closing as of #4001 defines the API layer with concepts.