[WIP] Update configuration from Manager server

[danbi2990]

Replace reload_config with update_config.

Close: #112

In this version, the `update_config` is effectively dead code (non-functional) because:

• if a local config is provided, the updated config is ignored by policy.
• if no local config is provided, the program cannot run normally due to the absence of last_timestamp_data.

As discussed, this will be addressed in a separate issue as follows:

• If no local config is provided, retrieve the config from the Manager server.
• If all attempts fail, the program will enter minimal mode.

About code details

1. There are code patterns like writer.lock().unwrap_or_else(std::sync::PoisonError::into_inner)
   which ignore the PoisonError, assuming that the log writer should not cause a
   panic even if another thread has poisoned the lock.

2. If log_dir changes by updating config, logs should be saved in that
   directory. This commit implements this by wrapping the file writer.
   Alternatively, tracing_subscriber::reload could be used, but it cannot
   handle cases where the directory is added or removed (as it requires
   reassigning the writer itself, which is not possible due to internal
   limitations).
   Related issue: Panic after reloading layer, combined with .with_filter tokio-rs/tracing#1629

[sehkone]

I think these should be combined into one item in the Changed section.

[danbi2990]

Applied the suggested adjustment.

[sehkone]

@sophie-cluml and @danbi2990,
Does calling this method guarantee that the update process will start? If not, we need to clarify that this method only attempts or plans to update the configuration.

[danbi2990]

Sophie and I discussed that the update process will be implemented in the next issue.
The next issue will proceed after the same functionality is completed for the Semi-supervised Engine.

[sehkone]

I don't get what you said. Is this going to wait for the next issue being completed? Or, this message will be handled later?

[danbi2990]

The latter is right. It will be handled later because it needs to fetch the configuration from the manager server.

[sehkone]

If this PR is temporarily being halted, it would be better to mention it to let others know of it.

[danbi2990]

The original plan was to merge this PR first and then implement the next issue.

I thought it was fine because this PR only changes the method name while maintaining the same behavior as before.

However, as you suggested, it seems reasonable to wait until the next issue is completed. For now, I will mark this PR as [WIP]. Thank you!

[sophie-cluml]

Since the linked issue of this PR, is handled by #131, let me close this PR. (cc. @danbi2990 When we manually close PR, we close it with a comment that describes why. This process is guided in our rule.)