Implement content-based equality to prevent redundant updates and storage bloat

[erral]

Problem

NamedFile and NamedBlobFile objects currently lack an __eq__ implementation, falling back to Python's default identity comparison. In the context of plone.restapi (or any code that replaces field values), this causes a major performance and storage regression:

When an image is PATCHed with the exact same bytes, the deserializer creates a new object instance. Because new_instance != old_instance, Plone perceives a change, triggers a ZODB write, fires an ObjectModifiedEvent, re-indexes the catalog, and invalidates all existing image scales.

Impact

In high-frequency update scenarios (like automated content imports), this leads to:

1. Massive Data.fs growth due to redundant transaction history.
2. Blob storage bloat from unnecessary scale regeneration.
3. Increased CPU load from redundant indexing and image processing.

Proposed Solution

1. Implement __eq__ in NamedFile and NamedBlobFile comparing contentType, filename, and a content checksum.
2. Introduce a private _hash attribute (SHA-256) calculated during _setData using chunked reading to save memory.
3. Update the internal _modified timestamp ONLY if the content hash actually changes.
4. ZODB Safety: For legacy objects lacking a _hash, the comparison should compute it in memory but MUST NOT save it back to the object during a read operation (avoiding "write-on-read").

[davisagli]

@erral For what it's worth, I think it's possible to work around this in the client by not sending the data if it hasn't changed. Of course that means you have to fetch the existing data to compare it, but then you can avoid sending the new data in the PATCH, so overall it's no worse in terms of amount of data transferred.

I like the idea of adding a checksum and using it to check equality and avoid unnecessary writes here. However I'd like to know what the impact is on write performance.

[erral]

Fair enough. I will prepare a performance review and report in the PR itself.