Driver support - support multiple version of evitaDB

[lukashornych]

Within #94, base ground for this support was set in form of internal evitaLab data layout and the Value wrapper. Currently, we will have a single driver built on top of gRPC-web of the latest evitaDB and we need to think about how will support future versions. Two possible version come to mind:

• create separate implementation of driver with converter for each evitaDB version that breaks an API
  • this will create lot of duplicate code, where possible driver bugs will be duplicated
  • over time, the browser will probably need to download lot of data from server (idk if tree shaking will help here if we will need the driver dynamically at runtime)
• create single driver implementation where the logic of supporting multiple APIs will be directly in the driver and converters (possibly using ifs and switches)
  • will not bloat in size as much as the first option
  • there will be much less duplicated code
  • it will be harder to maintain multiple versions using ifs and switches without breaking support of older drivers

There is also problem with the actual generated gRPC code, which would be kind of duplicated as well and would bloat the code base as well.

I personally don't like any of these solutions.

Second part will be to display useful information to users of evitaLab about supported features for a current evitaDB server #152.

[lukashornych]

Maybe we should get rid of the Value wrapper around properties and define default for unsupported properties directly in the converter in driver. The UI layer would be still handled as mentioned in #152 .

[lukashornych]

Early draft of proposed evitaDB client structure

flowchart TD
    Component --> EvitaClient
    Component --> EvitaManagementClient
    Component --> EvitaSessionClient
    EvitaClient --> VersionedEvitaDriver
    VersionedEvitaDriver --> VersionedGrpcEvitaAPI
    EvitaManagementClient --> VersionedEvitaManagementDriver
    VersionedEvitaManagementDriver --> VersionedGrpcEvitaManagementApi
    EvitaSessionClient --> VersionedEvitaSessionDriver
    VersionedEvitaSessionDriver --> VersionedGrpcEvitaSessionAPI
    VersionedGrpcEvitaAPI --> Server
    VersionedGrpcEvitaManagementApi --> Server
    VersionedGrpcEvitaSessionAPI --> Server
    VersionedEvitaDriver --> EvitaDriverConverters
    VersionedEvitaManagementDriver --> EvitaManagementDriverConverters
    VersionedEvitaSessionDriver --> EvitaSessionDriverConverters
    Component --> GraphQLClient
    GraphQLClient --> VersionedGraphQLClientDriver
    VersionedGraphQLClientDriver --> GraphQLAPI

Each evitaDB API would have its own versioned driver and client encapsulating the driver and versioning. This way we could upgrade each part separately and save some hassle of duplicating code. I still need to think more about relations to the #152