cleanup(falco): consolidate falco::grpc::server in one class

[LucaGuerra]

What type of PR is this?

Uncomment one (or more) /kind <> lines:

/kind cleanup

Any specific area of the project related to this PR?

Uncomment one (or more) /area <> lines:

/area engine

What this PR does / why we need it:

I was investigating the following warning from UBSan

/home/ubuntu/dev/falcosecurity/falco/userspace/falco/grpc_request_context.cpp:53:24: runtime error: member call on address 0x7fff2627bce0 which does not point to an object of type 'server'
0x7fff2627bce0: note: object has a possibly invalid vptr: abs(offset to top) too big
 eb 55 00 00  40 01 08 00 20 61 00 00  00 00 00 00 00 00 00 00  88 c6 24 9c eb 55 00 00  40 01 08 00
              ^~~~~~~~~~~~~~~~~~~~~~~
              possibly invalid vptr
    #0 0x55eb96fef9bb in falco::grpc::request_stream_context<falco::outputs::service, falco::outputs::request, falco::outputs::response>::process(falco::grpc::server*) /home/ubuntu/dev/falcosecurity/falco/userspace/falco/grpc_request_context.cpp:53
    #1 0x55eb96e11637 in falco::grpc::server::thread_process(int) /home/ubuntu/dev/falcosecurity/falco/userspace/falco/grpc_server.cpp:115
    #2 0x55eb96e92a4d in void std::__invoke_impl<void, void (falco::grpc::server::*)(int), falco::grpc::server*, int>(std::__invoke_memfun_deref, void (falco::grpc::server::*&&)(int), falco::grpc::server*&&, int&&) (/home/ubuntu/dev/falcosecurity/falco/build-sanitizers-
local/userspace/falco/falco+0xb069a4d)
    #3 0x55eb96e91398 in std::__invoke_result<void (falco::grpc::server::*)(int), falco::grpc::server*, int>::type std::__invoke<void (falco::grpc::server::*)(int), falco::grpc::server*, int>(void (falco::grpc::server::*&&)(int), falco::grpc::server*&&, int&&) (/home/ub
untu/dev/falcosecurity/falco/build-sanitizers-local/userspace/falco/falco+0xb068398)
    #4 0x55eb96e90777 in void std::thread::_Invoker<std::tuple<void (falco::grpc::server::*)(int), falco::grpc::server*, int> >::_M_invoke<0ul, 1ul, 2ul>(std::_Index_tuple<0ul, 1ul, 2ul>) (/home/ubuntu/dev/falcosecurity/falco/build-sanitizers-local/userspace/falco/falco
+0xb067777)
    #5 0x55eb96e840e5 in std::thread::_Invoker<std::tuple<void (falco::grpc::server::*)(int), falco::grpc::server*, int> >::operator()() (/home/ubuntu/dev/falcosecurity/falco/build-sanitizers-local/userspace/falco/falco+0xb05b0e5)
    #6 0x55eb96e6eac3 in std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (falco::grpc::server::*)(int), falco::grpc::server*, int> > >::_M_run() (/home/ubuntu/dev/falcosecurity/falco/build-sanitizers-local/userspace/falco/falco+0xb045ac3)
    #7 0x7f3b6cadc252  (/lib/x86_64-linux-gnu/libstdc++.so.6+0xdc252)
    #8 0x7f3b6be94ac2 in start_thread nptl/pthread_create.c:442
    #9 0x7f3b6bf2684f  (/lib/x86_64-linux-gnu/libc.so.6+0x12684f)

Essentially, what's happening is that request_stream_context<outputs::service, outputs::request, outputs::response>::process(server* srv) is trying to invoke (srv->*m_process_func)(*m_stream_ctx, m_req, res); which is assigned to &server::get. Now, the get() function is not defined in server (the type of srv) but in its base class server_impl. I read through some posts and documentation and I could not be convinced if this is undefined behavior (like UBSan was saying) or not.

However, after looking at these classes it looks like that there is only one derived class of server_impl which is server, where server acts as an interface with the rest of the code. Since it looked a bit odd that the interface derives from the implementation and there is no other use of this inheritance, I think it's safe to use a single class for the server. Any potential UB is gone and the files are a bit easier to read.

Which issue(s) this PR fixes:

Fixes #

Special notes for your reviewer:

Does this PR introduce a user-facing change?:

NONE

[FedeDP]

/milestone 0.38.0

[FedeDP]

/approve

[poiana]

LGTM label has been added.

Git tree hash: 4b46e2706c339ca4a3f84efa2989c03725f4bf69

[Andreagit97]

/approve

[poiana]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: Andreagit97, FedeDP, LucaGuerra

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [Andreagit97,FedeDP,LucaGuerra]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment