[FEAT] Simplify deployment

[NeonDaniel]

Objective

Document and update package to be more easily deployed (via Helm or Docker Compose).

Initial Implementation Requirements

• Implement configuration via ovos-config like other containers to simplify config file definitions (default config can specify working defaults and user config mounted as a volume into the container)
• Implement a docker-compose file with a MongodB container for simple local deployment

Other Considerations

• There will likely be some special considerations to handle MongodB data persistence
• Consider how to access conversation import/export

[NeonKirill]

@NeonDaniel it is a nice idea, and I did experiments with that, but it seems like it will require much more effort then I have affordable capacity. For the reference here are some step-by-step guide in case sometime in future there will be priority on that:

1. Implement configuration via ovos-config like other containers to simplify config file definition... [DONE]

2. It is required to split the pyklatchat repo into at least the following 5 (can be negotiated)
   • Pyklatchat Client (link to repo)
   • Pyklatchat Utils (link to repo)
   • Pyklatchat Server (not started as of 13.09.2023)
   • Pyklatchat Services (or Pyklatchat Observer as it is the only service we are using so far)
   • Pyklatchat Mongo Service (no specific configurations so far, probably just to build image from mongo)
3. Create docker-compose definitions in client/server/observer/mongo_service repos
4. Consider merging definition to the Neon services stack (tbd with @NeonDaniel)

Important things to note:

• currently there is base image definition which may be adopted somehow to distributed behavior (e.g. put it to pyklatchat utils repo)

@NeonBohdan FYI

[NeonDaniel]

Related to https://github.com/NeonGeckoCom/neon-diana-utils/pull/44

I think pyklatchat_utils may make sense to be rolled into a submodule of neon-utils; that could simplify the build process for the containers by making common modules importable without the current directory copying the Docker scripts do. From there I don't know if separating server/client/observer creates more work to maintain compatibility at this stage or if the API is stable enough to split those out to separate packages