Develop client-server IPC msg Performance exerciser for L3-LOC overheads

[gapisback]

This PR is a collection of multiple commits that incrementally build a client/server messaging program for use as a performance exerciser to measure overheads of L3/LOC diagnostic.

1. Initial version of client-server IPC msgs program sources.
2. Cleanup code-formatting in client-server IPC msgs program sources.
3. [Perf] Develop client-server comms. program to measure L3-logging overheads

---

Initial version of client-server IPC msgs program sources.

This commit adds the initial version of client-server messaging program sources as downloaded from Michael Kerrisk's reference book "The Linux Programming Interface".

Ref: https://man7.org/tlpi/code/online/all_files_by_chapter.html
Ch. 46: System V Message Queues.

Ref: [email protected]:bradfa/tlpi-dist.git

Required header files, along with the two main source files, svmsg_file_client.c and svmsg_file_server.c, are checked-in.

Makefile is updated to add the client-server-perf-test target which will build the client/server programs. Currently, as the server runs in an endless loop, we just build these programs but do not exercise these programs as part of CI.

Follow-on commits will adapt these core programs to develop a L3-LOC performance test exerciser.

Cleanup code-formatting in client-server IPC msgs program sources.

Tighten code-formatting in .c sources for client-server program sources inherited in previous commit.

• Consistently enclose single-line body of if(), else() conditionals in { }, to avoid any errors creeping-in due to future refactoring.
• Re-indent end */ markers of multi-line comment blocks to start on a newline.
• Enclose multiple |-separated status flags in ()

No code-logic change is introduced with this commit.

---

[Perf] Develop client-server comms. program to measure L3-logging overheads

This commit simplifies the simple client-server communication program to be usable as a performance test-bed to quantify the overheads of L3-logging. Basic single/multiple-clients exchanging n-messages with server
that runs in serial manner (of processing messages) is working with this [3rd] commit.

The changes are as follows:

svmsg_file.h:

• Define enum req_resp_type_t{} with few message types.
• Specifically of interest are: REQ_MT_INIT, REQ_MT_INCR, REQ_MT_EXIT

svmsg_file_server.c

• Simplified server. Receives messages inline from client in a forever loop. Currently, only implements "increment" counter.
• Manages state of multiple client connections using simple array
• L3-logging code is conditionally defined under L3_ENABLED. So, will need to build separately to invoke-and-test logging overheads.

svmsg_file_client.c

• Sits in forever loop, sending "increment" message to server
• Do this for n-iterations.

Makefile: Make changes to build the client/server programs with L3-logging OFF (baseline) and logging enabled.

test.sh: Add test-build-and-run-client-server-perf-test and include that in CI's build.yml . We will build-and-run a small scale run of this new test, with 5 concurrent clients, L3 ON and OFF.

---

Manual testing output

Here is how things will look when running this client-server application with a build where L3-Logging is enabled:

Server:

agurajada-Linux-Vm:[155] $ build/release/bin/use-cases/svmsg_file_server

Server: Initiate L3-logging to log-file '/tmp/l3.c-server-test.dat'                <<<<<
Server: Client ID=196636 joined. # active clients=1 (HWM=1)
Server: Client ID=196636 exited. # active clients=0
Server: # active clients=0 (HWM=1). Exiting.

Client:

agurajada-Linux-Vm:[815] $ build/release/bin/use-cases/svmsg_file_client 1000000
Client: ID=196636 Perform 1000000 message-exchanges to increment a number, 
with L3-logging enabled on server-side.         
^^^^^ Note msg reports that build is such that L3-logging code is active on server-side
..........
Client: ID=196636 Performed 1000000 message send/receive operations, ctr=1000000, 47476 ns/msg (avg) Exiting.

[gapisback]

Currently client only requests this op-type; i.e. increment.

Rest are added for possible future usages, but really serve no much purpose.

[gapisback]

Any L3-logging enabled on the server-side will be included in this elapsed-time region.

[gregthelaw]

Looking good!