[FEATURE] Rename agent_config to runtime_config

Is your feature request related to a problem? Please describe.

As time envolve, The agent config in https://github.com/eunomia-bpf/bpftime/blob/master/runtime/include/bpftime_config.hpp is no longer only for the agent. It should contain all the runtime config.

And also, the two config in

bpftime/runtime/syscall-server/syscall_context.cpp

Line 35 in 87a8901

const char *run_with_kernel_env = getenv("BPFTIME_RUN_WITH_KERNEL");

should be merged into the runtime config data struct and init in

bpftime/runtime/src/bpftime_config.cpp

Line 41 in 87a8901

const agent_config bpftime::get_agent_config_from_env()

Describe the solution you'd like

Rename all agent_config to runtime_config.
Move the config in syscall-server to bpftime_config

Should we consider using configuration library like https://www.boost.org/doc/libs/1_85_0/libs/config/doc/html/index.html ?

Since it will be more convenient to manage and parse configuration from multiple sources

It seems what you mentioned is not a config library, but how to config the boost library for different compiler/usecases

Any recommendations for libraries?

https://github.com/hyperrealm/libconfig maybe?

It seems our configurations are simple and don't need such libraries for management

Any recommendations for libraries?

Sorry, my fault, too sleepy now. Try libconfig

https://github.com/hyperrealm/libconfig maybe?

It seems our configurations are simple and don't need such libraries for management

Yes, this is what I would like to reocmmend. Though the configuration structure of bpftime is simple now, but it has a big chance to get more complicated in the future.

it has a big chance to get more complicated in the future

well...what kinds of new configuration would bpftime have in the future? I'm not quite sure about that.

I would suggest that we focus on the small number of configurations we have now, and don't need a library to handle that

it has a big chance to get more complicated in the future

well...what kinds of new configuration would bpftime have in the future? I'm not quite sure about that.

I would suggest that we focus on the small number of configurations we have now, and don't need a library to handle that

Ok, let's focus on configurations now and don't adopt a config library