…, and inserting comments around module and acl configs (#10761)

A regression from #10285 (redis 7.0).
CONFIG REWRITE would put lines with: `include`, `rename-command`,
`user`,  `loadmodule`, and any module specific config in a comment.

For ACL `user`, `loadmodule` and module specific configs would be
re-inserted at the end (instead of updating existing lines), so the only
implication is a messy config file full of comments.

But for `rename-command` and `include`, the implication would be that
they're now missing, so a server restart would lose them.

Co-authored-by: Oran Agra <oran@redislabs.com>

Use new module configuration API

RedisRaft adopts new configuration API: redis/redis#10285

After this commit, `RAFT.CONFIG` will not exist anymore. `CONFIG` command will be used instead. 

Usage: 

- Command: `config set raft.addr 127.0.0.1:8000` and `config get raft.id`
- CLI:   `./redis-server --port 5001 --loadmodule redisraft.so --raft.id 3 --raft.addr 127.0.0.1:8000`
- Config file: 
  ```
  ...
  port 5000
  dbfilename redis.rdb
  loadmodule /home/ozan/Desktop/redisraft/redisraft.so
  raft.addr 10.0.3.69:5022
  raft.slot-config 0:5460
  ```

------

**Breaking changes**

  1. `CONFIG` command will be used instead of `RAFT.CONFIG`  
  2. Configuration parameters will require `raft.` or `--raft.` prefix. 
 
  3. Renamed some configuration parameters:  

     | Old name  | New name |
     | ------------- | ------------- |
     | raft-log-filename  | log-filename |
     | raft-interval | periodic-interval |
     | raft-response-timeout | response-timeout |
     | raft-log-max-cache-size | log-max-cache-size |
     | raft-log-max-file-size | log-max-file-size |
     | raft-log-fsync | log-fsync | 

  4.  `join-timeout` config was in seconds. Now, it is in milliseconds.
       `connection-timeout` config was in microseconds. Now, it is in milliseconds.

The PR adds the ability to add module configuration as using configuration API introduced on Redis 7: redis/redis#10285

The configuration is added optionally on `redis_module!` macro under `configurations` list that can contains the following subsections:

* `i64` configuration:
A list of `i64` configuration in the following format: `[<name>, <reference to the configuration object>, <default value>, <min value>, <max value>, <flags>, <optional on update callback>]`

* `string` configuration:
A list of `string` configuration in the following format: `[<name>, <reference to the configuration object>, <default value>, <flags>, <optional on update callback>]`

* `bool` configuration:
A list of `bool` configuration in the following format: `[<name>, <reference to the configuration object>, <default value>, <flags>, <optional on update callback>]`

* `enum` configuration:
A list of `enum` configuration in the following format: `[<name>, <reference to the configuration object>, <default value>, <flags>, <optional on update callback>]`

An example of all the 4 options can be found under `example/configuration.rs`. Notice that `enum` configuration is of special type and require provide an `enum` that implements the following traits: `TryFrom<i32>`, `From<$name>`, `EnumConfigurationValue`, `Clone`. User can use `enum_configuration` macro to easily added those implementation on a given `enum`.

In addition, it is also possible to tell redismodule-rs to look at the module arguments as if they were configuration using `module_args_as_configuration: true/false` option.

Usage examample:

```rust
/// A macro to easily creating an enum that can be used as an enum configuration
enum_configuration! {
    enum EnumConfiguration {
        Val1 = 1,
        Val2 = 2,
    }
}

/// Static variable that can be used as configuration and will be automatically set when `config set` command is used.
/// All the variables must be somehow thread safe protected, either as atomic variable, `RedisGILGuard` or `Mutex`.
lazy_static! {
    static ref CONFIGURATION_I64: RedisGILGuard<i64> = RedisGILGuard::default();
    static ref CONFIGURATION_ATOMIC_I64: AtomicI64 = AtomicI64::new(1);
    static ref CONFIGURATION_REDIS_STRING: RedisGILGuard<RedisString> =
        RedisGILGuard::new(RedisString::create(None, "default"));
    static ref CONFIGURATION_STRING: RedisGILGuard<String> = RedisGILGuard::new("default".into());
    static ref CONFIGURATION_MUTEX_STRING: Mutex<String> = Mutex::new("default".into());
    static ref CONFIGURATION_ATOMIC_BOOL: AtomicBool = AtomicBool::default();
    static ref CONFIGURATION_BOOL: RedisGILGuard<bool> = RedisGILGuard::default();
    static ref CONFIGURATION_ENUM: RedisGILGuard<EnumConfiguration> =
        RedisGILGuard::new(EnumConfiguration::Val1);
    static ref CONFIGURATION_MUTEX_ENUM: Mutex<EnumConfiguration> =
        Mutex::new(EnumConfiguration::Val1);
}

/// This function will be called when a configuration change is done and will count the total number of changes.
fn num_changes(ctx: &Context, _: Vec<RedisString>) -> RedisResult {
    let val = NUM_OF_CONFIGERATION_CHANGES.lock(ctx);
    Ok(RedisValue::Integer(*val))
}

/// The module initialisation macro, gets the configuration variable and some extra data (such as configuration name and
/// default value) and pass it to Redis so Redis will set them and return their values on `config set` and `config get` respectively.
redis_module! {
    name: "configuration",
    version: 1,
    data_types: [],
    commands: [
        ["configuration.num_changes", num_changes, "", 0, 0, 0],
    ],
    configurations: [
        i64: [
            ["i64", &*CONFIGURATION_I64, 10, 0, 1000, ConfigurationFlags::DEFAULT, Some(Box::new(on_configuration_changed))],
            ["atomic_i64", &*CONFIGURATION_ATOMIC_I64, 10, 0, 1000, ConfigurationFlags::DEFAULT, Some(Box::new(on_configuration_changed))],
        ],
        string: [
            ["redis_string", &*CONFIGURATION_REDIS_STRING, "default", ConfigurationFlags::DEFAULT, Some(Box::new(on_configuration_changed))],
            ["string", &*CONFIGURATION_STRING, "default", ConfigurationFlags::DEFAULT, Some(Box::new(on_configuration_changed::<String, _>))],
            ["mutex_string", &*CONFIGURATION_MUTEX_STRING, "default", ConfigurationFlags::DEFAULT, Some(Box::new(on_configuration_changed::<String, _>))],
        ],
        bool: [
            ["atomic_bool", &*CONFIGURATION_ATOMIC_BOOL, true, ConfigurationFlags::DEFAULT, Some(Box::new(on_configuration_changed))],
            ["bool", &*CONFIGURATION_BOOL, true, ConfigurationFlags::DEFAULT, Some(Box::new(on_configuration_changed))],
        ],
        enum: [
            ["enum", &*CONFIGURATION_ENUM, EnumConfiguration::Val1, ConfigurationFlags::DEFAULT, Some(Box::new(on_configuration_changed))],
            ["enum_mutex", &*CONFIGURATION_MUTEX_ENUM, EnumConfiguration::Val1, ConfigurationFlags::DEFAULT, Some(Box::new(on_configuration_changed))],
        ],
        module_args_as_configuration: true, // Indication that we also want to read module arguments as configuration.
    ]
}
```

…, and inserting comments around module and acl configs (redis#10761)

A regression from redis#10285 (redis 7.0).
CONFIG REWRITE would put lines with: `include`, `rename-command`,
`user`,  `loadmodule`, and any module specific config in a comment.

For ACL `user`, `loadmodule` and module specific configs would be
re-inserted at the end (instead of updating existing lines), so the only
implication is a messy config file full of comments.

But for `rename-command` and `include`, the implication would be that
they're now missing, so a server restart would lose them.

Co-authored-by: Oran Agra <oran@redislabs.com>

PR #10285 introduced support for modules to register four types of
configurations — Bool, Numeric, String, and Enum. Accessible through the
Redis config file and the CONFIG command.

With this PR, it will be possible to register configuration parameters
without automatically prefixing the parameter names. This provides
greater flexibility in configuration naming, enabling, for instance,
both `bf-initial-size` or `initial-size` to be defined in the module
without automatically prefixing with `<MODULE-NAME>.`. In addition it
will also be possible to create a single additional alias via the same
API. This brings us another step closer to integrate modules into redis
core.

**Example:** Register a configuration parameter `bf-initial-size` with
an alias `initial-size` without the automatic module name prefix, set
with new `REDISMODULE_CONFIG_UNPREFIXED` flag:
```
RedisModule_RegisterBoolConfig(ctx, "bf-initial-size|initial-size", default_val, optflags | REDISMODULE_CONFIG_UNPREFIXED, getfn, setfn, applyfn, privdata);
```
# API changes
Related functions that now support unprefixed configuration flag
(`REDISMODULE_CONFIG_UNPREFIXED`) along with optional alias:
```
RedisModule_RegisterBoolConfig
RedisModule_RegisterEnumConfig
RedisModule_RegisterNumericConfig
RedisModule_RegisterStringConfig
```

# Implementation Details:
`config.c`: On load server configuration, at function
`loadServerConfigFromString()`, it collects all unknown configurations
into `module_configs_queue` dictionary. These may include valid module
configurations or invalid ones. They will be validated later by
`loadModuleConfigs()` against the configurations declared by the loaded
module(s).
`Module.c:` The `ModuleConfig` structure has been modified to store now:
(1) Full configuration name (2) Alias (3) Unprefixed flag status -
ensuring that configurations retain their original registration format
when triggered in notifications.

Added error printout:
This change introduces an error printout for unresolved configurations,
detailing each unresolved parameter detected during startup. The last
line in the output existed prior to this change and has been retained to
systems relies on it:
```
595011:M 18 Nov 2024 08:26:23.616 # Unresolved Configuration(s) Detected:
595011:M 18 Nov 2024 08:26:23.616 #  >>> 'bf-initiel-size 8'
595011:M 18 Nov 2024 08:26:23.616 #  >>> 'search-sizex 32'
595011:M 18 Nov 2024 08:26:23.616 # Module Configuration detected without loadmodule directive or no ApplyConfig call: aborting
```

# Backward Compatibility:
Existing modules will function without modification, as the new
functionality only applies if REDISMODULE_CONFIG_UNPREFIXED is
explicitly set.

# Module vs. Core API Conflict Behavior
The new API allows to modules loading duplication of same configuration
name or same configuration alias, just like redis core configuration
allows (i.e. the users sets two configs with a different value, but
these two configs are actually the same one). Unlike redis core, given a
name and its alias, it doesn't allow have both configuration on load. To
implement it, it is required to modify DS `module_configs_queue` to
reflect the order of their loading and later on, during
`loadModuleConfigs()`, resolve pairs of names and aliases and which one
is the last one to apply. "Relaxing" this limitation can be deferred to
a future update if necessary, but for now, we error in this case.

PR redis#10285 introduced support for modules to register four types of
configurations — Bool, Numeric, String, and Enum. Accessible through the
Redis config file and the CONFIG command.

With this PR, it will be possible to register configuration parameters
without automatically prefixing the parameter names. This provides
greater flexibility in configuration naming, enabling, for instance,
both `bf-initial-size` or `initial-size` to be defined in the module
without automatically prefixing with `<MODULE-NAME>.`. In addition it
will also be possible to create a single additional alias via the same
API. This brings us another step closer to integrate modules into redis
core.

**Example:** Register a configuration parameter `bf-initial-size` with
an alias `initial-size` without the automatic module name prefix, set
with new `REDISMODULE_CONFIG_UNPREFIXED` flag:
```
RedisModule_RegisterBoolConfig(ctx, "bf-initial-size|initial-size", default_val, optflags | REDISMODULE_CONFIG_UNPREFIXED, getfn, setfn, applyfn, privdata);
```
# API changes
Related functions that now support unprefixed configuration flag
(`REDISMODULE_CONFIG_UNPREFIXED`) along with optional alias:
```
RedisModule_RegisterBoolConfig
RedisModule_RegisterEnumConfig
RedisModule_RegisterNumericConfig
RedisModule_RegisterStringConfig
```

# Implementation Details:
`config.c`: On load server configuration, at function
`loadServerConfigFromString()`, it collects all unknown configurations
into `module_configs_queue` dictionary. These may include valid module
configurations or invalid ones. They will be validated later by
`loadModuleConfigs()` against the configurations declared by the loaded
module(s).
`Module.c:` The `ModuleConfig` structure has been modified to store now:
(1) Full configuration name (2) Alias (3) Unprefixed flag status -
ensuring that configurations retain their original registration format
when triggered in notifications.

Added error printout:
This change introduces an error printout for unresolved configurations,
detailing each unresolved parameter detected during startup. The last
line in the output existed prior to this change and has been retained to
systems relies on it:
```
595011:M 18 Nov 2024 08:26:23.616 # Unresolved Configuration(s) Detected:
595011:M 18 Nov 2024 08:26:23.616 #  >>> 'bf-initiel-size 8'
595011:M 18 Nov 2024 08:26:23.616 #  >>> 'search-sizex 32'
595011:M 18 Nov 2024 08:26:23.616 # Module Configuration detected without loadmodule directive or no ApplyConfig call: aborting
```

# Backward Compatibility:
Existing modules will function without modification, as the new
functionality only applies if REDISMODULE_CONFIG_UNPREFIXED is
explicitly set.

# Module vs. Core API Conflict Behavior
The new API allows to modules loading duplication of same configuration
name or same configuration alias, just like redis core configuration
allows (i.e. the users sets two configs with a different value, but
these two configs are actually the same one). Unlike redis core, given a
name and its alias, it doesn't allow have both configuration on load. To
implement it, it is required to modify DS `module_configs_queue` to
reflect the order of their loading and later on, during
`loadModuleConfigs()`, resolve pairs of names and aliases and which one
is the last one to apply. "Relaxing" this limitation can be deferred to
a future update if necessary, but for now, we error in this case.