feat: store id_hash_keys in Document objects to make documents clonable

[ZanSara]

Related Issues

• extracted from feat: split PreProcessor #3557
• See previous discussions:
  • Property id_hash_keys of documents never set #1920
  • Custom id hashing on documentstore level #1910

Proposed Changes:

• Make Document object store their id_hash_key attribute after initialization. This allows nodes to "clone" the way Documents were created, for example when splitting or merging them together, and saves the user the burden to keep specifying the id_hash_key parameter every time.
• Fixes ES and Weaviate to properly manage id_hash_keys
• Fixes a few docstrings & typing in the Document class
• Remove some dangerous defaults in the Document class, mainly the field_maps.

How did you test it?

• Unit tests

Notes for the reviewer

Read the related discussions linked above as they contain valuable insights about why this feature was initially dismissed.

Note also that the possibility to pass an ID to the init of Document might have been an early workaround to the fact that id_hash_keys was lost. We might want to reconsider this feature later on.

Checklist

• I have read the contributors guidelines and the code of conduct
• I have updated the related issue with new insights and changes
• I added tests that demonstrate the correct behavior of the change
• I've used the conventional commit convention for my PR title
• I documented my code
• I ran pre-commit hooks and fixed any issue

[bogdankostic]

Left a few comments, mostly regarding doc strings. Also, I think we should follow our deprecation policy here, even though this is a minor change.

[ZanSara]

Also, I think we should follow our deprecation policy here, even though this is a minor change.

I'm not sure how to proceed here. This PR is mostly about persisting a parameter that has always been given to the Document. We could argue I'm adding stuff rather than removing it. Where can I add the deprecation notice? Do you have a specific API in mind?

[bogdankostic]

Where can I add the deprecation notice? Do you have a specific API in mind?

I thought of adding category=FutureWarning, stacklevel=2 at this deprecation warning message and adding a test that uses id_hash_keys parameter in from_dict that will fail in v1.15.

[bogdankostic]

LGTM