[ENH] Make storage_prefix_for_log a property of the CollectionUuid.

[rescrv]

Description of changes

This creates a method on the CollectionUuid that says its prefix relative to the storage root.

Test plan

CI

Documentation Changes

N/A

[propel-code-bot]

This PR refactors how the log storage prefix is determined by moving the storage_prefix_for_log functionality from a standalone function in the log-service crate to a method on the CollectionUuid type in the types crate. All usages have been updated to call this new method, ensuring that any component with a CollectionUuid can directly compute its log storage path.

This summary was automatically generated by @propel-code-bot

[github-actions]

Reviewer Checklist

Please leverage this checklist to ensure your code review is thorough before approving

Testing, Bugs, Errors, Logs, Documentation

• Can you think of any use case in which the code does not behave as intended? Have they been tested?
• Can you think of any inputs or external events that could break the code? Is user input validated and safe? Have they been tested?
• If appropriate, are there adequate property based tests?
• If appropriate, are there adequate unit tests?
• Should any logging, debugging, tracing information be added or removed?
• Are error messages user-friendly?
• Have all documentation changes needed been made?
• Have all non-obvious changes been commented?

System Compatibility

• Are there any potential impacts on other parts of the system or backward compatibility?
• Does this change intersect with any items on our roadmap, and if so, is there a plan for fitting them together?

Quality

• Is this code of a unexpectedly high quality (Readability, Modularity, Intuitiveness)

[HammadB]

Is there a compelling reason for this change? I'd argue it breaks encapsulation of the collection type from the storage layout of the log. The log should know where it wants to keep collections. The collection shouldn't say where it wants to be stored

[rescrv]

@HammadB Yes. I need this information to be known by the garbage collector that calls wal3::LogWriter::garbage_collect. It cannot stay in log-service without linking that whole crate into garbage collector. This was the most logical place.

[HammadB]

Makes sense! Thanks