[fix](query) improve performance total count using cache

[areski]

count might seem innocent, but it quickly can get very painful if you are working with millions of records.

In this PR, we first change count(r.d) by count(*), the second is slightly more performant, it might be counter intuitive but an explanation is giving here why https://www.cybertec-postgresql.com/en/postgresql-count-made-fast/

There is a tiny of refactoring to have a single source for counting through total_count

Finally, we introduce a caching, this is definitely arguable.
I can understand many good reason for trying to keep the deps as low as possible in kaffy.

We could certainly implement our own cache: https://thoughtbot.com/blog/make-phoenix-even-faster-with-a-genserver-backed-key-value-store if really using cachex.
Having say that cachex seems to be a very well tested packages.

Personally I have been using https://github.com/melpon/memoize heavily in a backend service production but it seems that cachex might be a better fit for phoenix and it's certainly more active.

[aesmail]

Your point is very valid. This definitely needs a fix. Currently with some resources, I have to wait a few seconds before the page could render which is not fun.

We could use cachex, however I feel very uneasy adding it (which adds its own dependencies) just to temporarily hold simple numbers. As you mentioned, this could easily be implemented in a few lines with GenServer or even with ETS which are both built into elixir.

It's almost as easy as:

:ets.new(:total_count, [:named_table])
:ets.insert(:total_count, {"schema_count", 3_000_000})
count = :ets.lookup(:total_count, "schema_count")
# count = [{"schema_count", 3000000}]

This needs just a couple more lines to check if the :total_count table already exists with an entry for "reseting" the values after a few minutes.

Either way, this problem needs to be fixed. And I recommend using our own extremely simple solutions as oppose to using an external dependency.