Partly remove the notion of entry sizes for non-blobs

[jrray]

This kind of change is desired to eliminate a problem of spfs diff reporting changes to directory sizes.

However, the size value associated with non-blob entries is still needed in order to preserve the same on-disk representation and digest calculated for manifests.

[rydrman]

Haiving the EntryKind::Blob hold data feels like it breaks the design pattern here, but I appreciate that any other change would need to be much more involved

[jrray]

Haiving the EntryKind::Blob hold data feels like it breaks the design pattern here, but I appreciate that any other change would need to be much more involved

A common pattern I see is a combination of a struct and an enum for when you want to have an enum but all arms the enum would share the same field. Those shared fields get pushed down into the struct and the enum itself only has fields that are unique to each arm. This pattern helps prevent bugs by making it impossible to describe something meaningless, like give non-blobs a size.

I pushed an update to resolve conflicts, it was just from some tests moving to a different file. If you want to have a look again. Otherwise I'll merge this in a day or so.

[rydrman]

Maybe it's more about the naming and existing usage being focused on describing exactly the kind because I agree with the pattern that you are describing. In any case, I'm not suggesting further changes at this point - just closing the discussion