feat(sync): 支持 RDB 临时文件压缩

[DCjanus]

背景

sync_reader 当前会先把源端全量 RDB 写入本地临时 dump.rdb 文件，再从该文件解析并写入目标端。对于较大的 RDB，这会占用较多本地磁盘空间，也会增加全量同步阶段的磁盘 I/O 压力。

这个 PR 先实现 #1053 中 RDB 临时文件压缩的部分。AOF 临时文件涉及持续写入、读取、轮转和 offset 管理，后续可以在统一临时存储抽象后继续推进。

改动内容

• 新增 advanced.temp_file_compression_rdb，用于控制 sync_reader 内部 RDB 临时文件压缩。
• 支持 none、snappy、zstd 三种取值。
• 默认使用 snappy，在降低临时文件磁盘占用的同时尽量控制 CPU 开销。
• 解析压缩临时文件时使用流式解压，不额外生成第二份解压后的临时文件。
• 用户显式配置的 rdb_reader.filepath 不受影响，仍按原始 RDB 文件读取。

默认压缩算法

这里有一个希望 reviewer 重点关注的取舍：默认把 RDB 临时文件从原始格式改为 snappy 压缩是否合适。

从目前的本地测试结果看，snappy 压缩速度很快，CPU 开销较低，因此默认启用看起来是可以接受的行为变化。对最终使用者来说，RedisShake 4.x 本身不支持 checkpoint/resume；sync_reader 启动时会清理并重建当前 reader 的临时目录，RDB 解析完成后也会删除临时文件。因此这个默认值变化不会影响最终同步数据语义，也不会涉及旧进程 RDB/AOF buffer 的复用。

如果用户需要保留原始临时文件格式，可以显式配置：

[advanced]
temp_file_compression_rdb = "none"

Related to #1053

验证

• go test ./...

[suxb201]

不希望有压缩，RDB 一般比较小，该功能会带来额外复杂度。

[DCjanus]

不希望有压缩，RDB 一般比较小，该功能会带来额外复杂度。

了解，我们之前在内部 fork 版本里实现了类似功能，因为我们有些 GB 级别的 RDB。

不过这确实是我们内部服务治理的问题，看起来不是通用需求