…nabled

…d-and-gql-query-doesnt-contain-query-name

fix(#532): NPE when GQL query is sent without a name and tracing is enabled

…r work with the multiline text inside

…an better work with the multiline text inside"

This reverts commit 9eb443e.

… work with the multiline text inside

…n-json-layout

 fix(#534): log exception with log message so that consumers can better work with the multiline text inside

…es into account

Equal date times:

- `2024-04-24T11:07:11.677467736Z`
- `2024-04-24T13:07:11.677467736+02:00`

were considered different. Also, the filter index didn't take string collations into account, so less than & greater than didn't work properly for strings containing national characters.

The fix changed the format of the stored data, so I had to include a backward compatible deserializer so that existing data is loaded correctly. When the data is saved again, it has the correct new format. The old format should be automatically removed by compaction.

…version-on-the-way-from-the-client-to-the-server

fix (#536): Invalid OffsetDateTime comparison taking offset difference into an account

When UserFilterFormula was not part of the computational tree, the facet impact computation didn't work well.

…-difference-when-userfilter-is-used

fix(#537): Incorrect facet statistics difference when userFilter is used

There's a transactional boolean `dirty` in many places in transactional data structures, but it's not taken into account in the `io.evitadb.core.transaction.memory.TransactionalLayerProducer#createCopyWithMergedTransactionalMemory` method, which is called when a new state is created. If we had taken advantage of this flag and just returned "this" reference in cases where it's not dirty, we could save a lot of memory allocations. If nothing has changed, we can reuse the exact same instance of the object for the next generation.

…changes-in-indexes-occur

refactor(#542): Limit allocations when no changes in indexes occur