Add support for indexes in v2 connection instantiation

[fnocetti]

Is your feature request related to a problem? Please describe. Up to this point we have more or less agreed that the indexes on Mongo would be created on migrations. This presents a problem for the testing strategies. The migrations are meant to be run one after the other starting from an original data structure that is many years old. In the case of the tests, the fixtures are designed with the up-to-date structure. That means that even applying the migration to the fixtures won't make a good strategy. The test need to ensure that the index is in place in order to be valid, but that's error and duplication prone.

Describe the solution you'd like When using Mongoose, we had a declarative way to say which indexes we wanted in place, and Mongoose will make sure they exists at some point during start up. We want to achieve something similar to happen during the instantiation of the tenant's connection to the database. Our approach should also ensure that indexes that were removed from the register are removed from Mongo.

Additional context We have a function called getConnection that uses the v1 tenants context to obtain a connection. We will need to work from there, either extending from that point or creating a v2 version of the connection instantiation.

[txau]

@fnocetti if this is already solved in Mongoose, is it possible to use Mongoose just for data structure maintenance, but not so much for data CRUD operations?

[fnocetti]

From the perspective of the feasibility, yes, we can. It will imply maintaining some awkward integrations, tho. On the other hand, Mongoose is a pretty big library and maintaining it only to use this kind of functionality doesn't seem like the right thing to do to me. We have also decided some time ago that we want slowly move away from Mongoose since the driver is simpler, less opinionated and more powerful. Also, we've seen that the index ensuring on Mongoose doesn't delete indexes upon un-declaration. Let's discuss this matter in a tech call.

[txau]

@fnocetti I guess it makes sense to move away from Mongoose. I would just consider other libraries, maybe something lightweight, if there is any before implementing our own.