feat(cache): add backward compatibility for pako 1.x to 2.x migration

[elaine-mattos]

Hi,

as part of the Node.js and package updates effort (#1340), here is the follow-up PR that adds backward compatibility to handle Redis cache entries compressed with both pako 1.x (binary string) and pako 2.x (base64) formats, preventing cache invalidation during the upgrade.

Summary

Adds backward compatibility to handle Redis cache entries compressed with both pako 1.x (binary string) and pako 2.x (base64) formats, preventing cache invalidation during the upgrade.

Changes

• Format detection in redis.js: Automatically detects whether cached data is in old binary string format (pako 1.x) or new base64 format (pako 2.x)
• Backward compatibility: Existing cache entries remain readable after upgrading to pako 2.x
• Test coverage: Added comprehensive tests for both def_* (definitions) and hrv_* (harvest) key patterns

Testing

• Unit tests verify reading both old (pako 1.x binary) and new (pako 2.x base64) formats
• Tested with local Redis container using keys written with pako 1.x and read with pako 2.x
• Tests use both pako@1.0.8 and pako@2.1.0 to prove cross-version compatibility

Benefits

• Zero cache invalidation on deployment
• Seamless migration from pako 1.x to 2.x
• Both formats coexist during transition period

[JamieMagee]

Was the removal of || 6380 here intentional? redis.js has it in the function signature default, and config.js has added the fallback.

[JamieMagee]

nit: sort alphabetically.

[qtomlinson]

Thanks for adding the migration and the unit tests!

[qtomlinson]

duplicate? pako is already listed in dependencies.

[JamieMagee]

It looks like it's pako v1 and v2 for backwards compat.

[qtomlinson]

Most of our cached values are objects and this works well for those cases. When a number is cached (e.g. statusService.requestCount), isBase64 becomes false positive. The number of such cases is small.