Implement proper FK in MetaDocumentORM and MetaLabelORM to work on PostgreSQL

[ZanSara]

Implement a proper composite FK key for DocumentORM and LabelORM in MetaDocumentORM and MetaLabelORM respectively, to allow for the same ID in two different indices. This was not enforced by SQLite, but crashes "strict" databases like PostgreSQL.

Also modifies the tests to make them runnable on PostgreSQL, although for now the tests will still run on SQLite on the CI.

---

It's a breaking change because it modifies the SQL schema. Previously saved SQLite databases might not work with the current implementation. It's recommended to re-create them from scratch.

[ZanSara]

Changes needed to fix the bug:

• Modify the small ORM classes in haystack/document_stores/sql.py
• update_document_meta() was identifying documents only by index. This is now fixed by defaulting to the default index and adding a parameter that allows users to select a different one if needed.

Changes required to make the tests runnable:

• SQLDocumentStore accepts a isolation_level parameter, which forced me to add it to FAISSDocumentStore and both MilvusDocumentStores
• Many tests and fixtures had to be modified to remove the explicit sqlite:/// path and replace it with a proper URL that depends on an env var placed in tests/conftest.py
• Many tests had to include an explicit isolation_level="AUTOCOMMIT" param with initializing their docstore
• In some occasions the function get_document_store was used directly in tests instead of being used as a fixture, but to allow the tests to run on PostgreSQL, I needed to ensure a teardown was executed. The easiest way to do it was to convert the return into a yield, with ugly consequences (see diff). I think this might be tolerable for now, and will definitely be dealt with as part of the DocumentStore's refactoring (Rethink Document Stores #1897).

In addition, a few tests were relocated from test_faiss_and_milvus to test_document_stores as they were generic enough to stay there.

[tholor]

SQL part looks good! Just wondering if we can simplify the tests a bit. Seems to me that we are convoluting things even more with this PR and make the tests harder to read.

[tholor]

Would it simplify things if we use get_document_store() here instead? Maybe we can get rid of the sql_url fixture then?

[ZanSara]

I'd rather use a fixture than a direct function call. What could be the advantage of using get_document_store() here? In general direct use of get_document_store() in the tests is something that gave me a lot of pain in this PR, and left me quite puzzled, so I might be missing something crucial...

[tholor]

You are right. In general, a fixture would be nicer.
I think the history of this goes like this: some tests require passing quite special parameters to the document store (here: progress_bar=False). Instead of adding this as an "optional parameter" to the document_store fixture, we instantiated the document store just within the test. The get_document_store is probably something in the middle of the two approaches that avoids duplicate code across a few tests that require the same instantiation without polluting the document_store fixture.
However, if we find an elegant way to add all those optional params to the document store fixture itself, this would make things probably cleaner.

[tstadel]

The fix looks good to me. However I would prefer the global init/teardown of postgres instead of getting a lot of cluttered/ugly places in the tests.