[history server] remove unused function in RayLogHandler

[AndySung320]

Why are these changes needed?

Remove three functions (AddLogFile, PushLog, WatchLogsLoops) from RayLogHandler that are no longer part of the current implementation.

The current log collection uses:

• processSessionLatestLogs() - Processes logs on SIGTERM/shutdown
• WatchPrevLogsLoops() - Watches /tmp/ray/prev-logs for crash recovery
• processPrevLogsDir() - Directly processes log directories

According to the design document, the collector has evolved:

• Old approach (removed): Channel-based queueing with AddLogFile() and batch processing with PushLog()
• Current approach: Event-driven processing with fsnotify, logs flushed on SIGTERM

Related issue number

Closes #4322

Checks

• I've made sure the tests are passing.
• Testing Strategy
  • Unit tests
  • Manual tests
  • This PR is not tested :(

[AndySung320]

While removing these functions, I found the some unused fields (LogFiles, PushInterval, LogBatching, HttpClient, SessionDir) also exist in:

• Storage backends: s3.go, aliyunoss/ray/ray.go
• Config: types.go
• CLI flags in main.go
• Validation: ValidateRayHanderConfig() never called.

They seem to be alpha to beta transition artifacts based on the design doc.

Unclear: SessionDir

• Log collector has it but uses hardcoded /tmp/ray paths instead
• Storage backends (s3.go, aliyunoss/ray.go) receive it and compute paths from it
• Not sure if storage backends use the stored value or if it's also dead code

Should I expand this PR or create follow-up issues? The SessionDir situation needs investigation (does storage backend actually use it vs. should they also use hardcoded paths?).

cc @Future-Outlier would appreciate guidance on scope~

[Future-Outlier]

While removing these functions, I found the some unused fields (LogFiles, PushInterval, LogBatching, HttpClient, SessionDir) also exist in:

• Storage backends: s3.go, aliyunoss/ray/ray.go
• Config: types.go
• CLI flags in main.go
• Validation: ValidateRayHanderConfig() never called.

They seem to be alpha to beta transition artifacts based on the design doc.

Unclear: SessionDir

• Log collector has it but uses hardcoded /tmp/ray paths instead
• Storage backends (s3.go, aliyunoss/ray.go) receive it and compute paths from it
• Not sure if storage backends use the stored value or if it's also dead code

Should I expand this PR or create follow-up issues? The SessionDir situation needs investigation (does storage backend actually use it vs. should they also use hardcoded paths?).

cc @Future-Outlier would appreciate guidance on scope~

good question, can you ask this question in the history sever's dev channel in ray's slack?
Thanks!

[Future-Outlier]

lgtm, thank you