Add API UpdateRuntimeArgs for updating the module arguments during runtime

[hwware]

Before Redis OSS 7, if we load a module with some arguments during runtime,
and run the command "config rewrite", the module information will not be saved into the
config file.

Since Redis OSS 7 and Valkey 7.2, if we load a module with some arguments during runtime,
the module information (path, arguments number, and arguments value) can be saved into the config file after config rewrite command is called.
Thus, the module will be loaded automatically when the server startup next time.

Following is one example:

bind 172.25.0.58
port 7000
protected-mode no
enable-module-command yes

Generated by CONFIG REWRITE
latency-tracking-info-percentiles 50 99 99.9
dir "/home/ubuntu/valkey"
save 3600 1 300 100 60 10000
user default on nopass sanitize-payload ~* &* +https://github.com/ALL
loadmodule tests/modules/datatype.so 10 20

However, there is one problem.
If developers write a module, and update the running arguments by someway, the updated arguments can not be saved into the config file even "config rewrite" is called.
The reason comes from the following function
rewriteConfigLoadmoduleOption (src/config.c)

void rewriteConfigLoadmoduleOption(struct rewriteConfigState *state) {
..........
struct ValkeyModule *module = dictGetVal(de);
line = sdsnew("loadmodule ");
line = sdscatsds(line, module->loadmod->path);
for (int i = 0; i < module->loadmod->argc; i++) {
line = sdscatlen(line, " ", 1);
line = sdscatsds(line, module->loadmod->argv[i]->ptr);
}
rewriteConfigRewriteLine(state, "loadmodule", line, 1);
.......
}

The function only save the initial arguments information (module->loadmod) into the configfile.

After core members discuss, ref #1177

We decide add the following API to implement this feature:

Original proposal:

int VM_UpdateRunTimeArgs(ValkeyModuleCtx *ctx, int index, char *value);

Updated proposal:

ValkeyModuleString **values VM_GetRuntimeArgs(ValkeyModuleCtx *ctx);
**int VM_UpdateRuntimeArgs(ValkeyModuleCtx *ctx, int argc, ValkeyModuleString **values);

Why we do not recommend the following way:

MODULE UNLOAD
Update module args in the conf file
MODULE LOAD

I think there are the following disadvantages:

1. Some modules can not be unloaded. Such as the example module datatype.so, which is tests/modules/datatype.so
2. it is not atomic operation for MODULE UNLOAD + MODULE LOAD
3. sometimes, if we just run the module unload, the client business could be interrupted

[codecov]

Codecov Report

Attention: Patch coverage is 8.33333% with 11 lines in your changes missing coverage. Please review.

Project coverage is 70.86%. Comparing base (a401e37) to head (263b276).
Report is 1 commits behind head on unstable.

Files with missing lines	Patch %	Lines
src/module.c	8.33%	11 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##           unstable    #1041      +/-   ##
============================================
+ Coverage     70.69%   70.86%   +0.16%     
============================================
  Files           118      118              
  Lines         63549    63561      +12     
============================================
+ Hits          44924    45040     +116     
+ Misses        18625    18521     -104     

Files with missing lines	Coverage Δ
src/module.c	9.64% <8.33%> (-0.01%)	⬇️

... and 15 files with indirect coverage changes

[zuiderkwast]

Looks simple, but what's the use case? Why does a module need to update args in runtime?

A module can already have config that is updated using CONFIG SET, right?

[hwware]

@zuiderkwast I update the top description for this PR, i think this is a good way to access the updated module arguments. Pls take a look when you have time, Thanks a lot

[zuiderkwast]

You added a module API to access the argv. Interesting.

But, I am not convinced. :)

In a program written in C, the arguments are passed to main as int main(int argc, char **argv). It's not possible to change these args later, from outside the program, while the program is running.

The argv for MODULE LOAD is the same. If you set the arguments with MODULE SET-ARGUMENTS later, the module was still loaded with the old arguments and most modules (or new modules like valkey-bloom) will not notice the arguments have changed. But there will be a problem. In the log, it looks like the module is using the new arguments, even if it is using the old arguments.

MODULE UNLOAD + MODULE LOAD doesn't have this problem.

[hwware]

You added a module API to access the argv. Interesting.

But, I am not convinced. :)

In a program written in C, the arguments are passed to main as int main(int argc, char **argv). It's not possible to change these args later, from outside the program, while the program is running.

The argv for MODULE LOAD is the same. If you set the arguments with MODULE SET-ARGUMENTS later, the module was still loaded with the old arguments and most modules (or new modules like valkey-bloom) will not notice the arguments have changed. But there will be a problem. In the log, it looks like the module is using the new arguments, even if it is using the old arguments.

MODULE UNLOAD + MODULE LOAD doesn't have this problem.

Thanks for your comment, but some cons for operation MODULE UNLOAD + MODULE LOAD

1. some modules maybe not unloaded. Such as the example module datatype.so, which is tests/modules/datatype.so
2. it is not atomic operation for MODULE UNLOAD + MODULE LOAD
3. sometimes, if we just run the module unload, the client business could be interrupted
4. through the way MODULE UNLOAD + MODULE LOAD to update module runtime args, the management plan and data plan software need to be updated as well.

I would like to create an issue to let community to discuss this problem. Thanks

[hwware]

@madolson As we discussed, I desgin the API as int VM_UpdateRuntimeArgs(ValkeyModuleCtx *ctx, int argc, ValkeyModuleString **argv), please take a look, Thanks

[zuiderkwast]

Looks good to me. Only documentation comment missing.

What about VM_GetRuntimeArgs, is it not needed?

[hwware]

I update some logic in module.c, now it works well. @zuiderkwast

[zuiderkwast]

Yes, now it looks better. Before, it couldn't work. :D

Just some small comment now, then ready to merge I think.

[zuiderkwast]

LGTM