Timescale parity

[c0c0n3]

This PR makes all QL API endpoints work with Timescale as a backend. From now on, we should be able to use either backend (Crate or Timescale) to store, query and delete NGSI entity data. We can even use both backends at the same time, routing requests to either DB depending on tenant. But notice there still are some differences between the two:

• The Crate backend only supports arrays of strings whereas Timescale accepts any JSON array;
• You can use any NGSI SLF type (point, line, polygon, box) with Timescale whereas Crate is restricted to points;
• Crate doesn't support equality testing of geo shapes but Timescale does.

Notice this PR implements new modules and functions to fully support geo queries targeting Timescale---see changes in geocoding and sql packages as well as the timescale_geo_query module in the translators package. This PR also implements a number of fixes, tweaks and additions to make the existing translator modules work smoothly with both backends on inserting data and formatting query result sets into JSON---see changes in the translators package.

[c0c0n3]

@chicco785 so I've put together basically everything we need for Timescale as a backend in this PR, instead of splitting query support and all the rest (insert/formatting/other tweaks) in two separate PRs since it turned out to be less work this way. But there are still a few things I haven't got around to doing yet:

• Geo equality. Equality isn't supported in Crate and the reporter blindly returns a 422 regardless of backend. That will have to change since the Timescale backend can actually do equality tests. Then the test_geo* modules should be updated accordingly so that in the case of Timescale we check equality works!
• Health endpoint. Hardcoded to work with Crate only, we'll have to decide what to do here but I suppose it's best left out of this PR. Whatever we eventually do, test_health should be updated accordingly.
• Reporter tests. They still need some love. At the moment there's a separate test suite for Timescale, but like you said we could just have one test suite by adding Timescale to the existing Docker compose file and then route query tests to either backend using the existing service argument. This works for the query tests, for these other tests we'll have to decide what to do:
  • test_integration: works with Crate, possibly not needed for Timescale.
  • test_multitenancy: ditto.
  • test_notify: test_no_value_no_type_for_attributes is broken but it looks like the test was wrong to start with. In fact, the test checks (among other things) that a numeric attribute (temperature) with a string value ('25') is inserted in Crate with a text column type. The Timescale backend inserts it as float, which is correct?
  • test_sql_injection: needs some massaging to make it work with Timescale too.
  • test_subscribe: ditto.
  • test_time_format: in principle these tests should be able to work with both backends but during test setup we connect to Crate.

[chicco785]

@c0c0n3 any reason to keep it draft?

[c0c0n3]

@chicco785

any reason to keep it draft?

still working on it, would like to sort out the reporter tests...i.e. last point in the task list above

[c0c0n3]

I opened issues for all items in the above task list, see: #375, #376, #377, #378.
We can review and merge this PR...

[chicco785]

LGTM