Refactor SQL storage layer using ORM

[nabokihms]

Is your feature request related to a problem? Please describe.
Refactoring of SQL level was previously suggested here -
#1831 (comment)

Describe the solution you'd like to see
Back in the days, there weren't fully statically typed convenient ORMs for golang. Now we have such a tool - ent from Facebook. The main advantages are:

1. Query constructor
2. Migration
3. Static types

Describe alternatives you've considered
Leave SQL storage layer as is.

Additional context
I wonder, is it ok to start working on this one? Ent is lovely, we use it for a couple of projects. @sagikazarmark Have you already started working on this?

Roadmap:

• Update dex dependencies Update project dependencies #1925
• Describe database schema using ent feat: Add ent-based sqlite3 storage #1906
• Make ent-based sqlite3 storage feat: Add ent-based sqlite3 storage #1906
• Make ent-based postgres storage feat: Add ent-based postgres storage #2121
• Make ent-based mysql storage feat: Add MySQL ent-based storage driver #2272
• Add storage documentation (how to enable/setup/migrate)
• Migrate from using raw SQL query storage to ent-based storage by default

[al45tair]

It'd be nice to get my middleware changes in first :-) (See #1841.)

Otherwise, there's going to be quite a lot to change in that patch.

[sagikazarmark]

I think that's a great idea. I'm actually looking at it for quite some time now, but always lacked the time to implement it. I think ent is a great choice, although I don't have a lot of experience with it other than a few simple applications. It's probably the first decent ORM for Go, at least I have terrible experience with basically all other Go ORMs.

@al45tair I would assume that this storage driver would actually be a new one, not a rewrite of the existing ones. Do you think that would still affect your PR negatively?

[al45tair]

@sagikazarmark It's not so much that it'll affect it negatively; rather, if this is done first, it'll mean I've got to work out how to extend the new storage driver as well. It's OK, as long as it's clear enough what to do :-)

And you're right, if it's a new storage driver, it won't have too much of a negative impact.

[nabokihms]

Maybe we could also generate the grpc API code from the ent schema as well
https://entgo.io/blog/2021/06/28/gprc-ready-for-use/

/cc @sagikazarmark

[sagikazarmark]

Not a huge fan of the idea. I don't really like binding the storage layer to the API or the transport.

[sagikazarmark]

What's the state of this @nabokihms ? I believe most of the implementation is done, right?

[nabokihms]

The only step left is to provide and test the migration. I haven't had time to work on this one.