Load RAG database in memory on use.

[blkt]

This change uses a trick to force the RAG database into memory by dumping the SQLite database from file to a temporary in-memory version of it using SQLite's backup function.

Based on percall statistic, this almost halves execution times.

With on-disk database.

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
      911    0.017    0.000   47.983    0.053 .../src/codegate/storage/storage_engine.py:149(search)
      911   41.336    0.045   41.336    0.045 {method 'execute' of 'sqlite3.Cursor' objects}
      911    0.007    0.000    6.489    0.007 .../src/codegate/inference/inference_engine.py:90(embed)

With in-memory database.

ncalls  tottime  percall  cumtime  percall filename:lineno(function)
   658    0.009    0.000   21.198    0.032 .../src/codegate/storage/storage_engine.py:147(search)
   658   16.458    0.025   16.458    0.025 {method 'execute' of 'sqlite3.Cursor' objects}
   658    0.004    0.000    4.638    0.007 .../src/codegate/inference/inference_engine.py:90(embed)

Also, added profiling to providers and search. Profiling can be activated exporting CODEGATE_PROFILE_<key> where <key> is the string passed to @profiled annotations. Profiling points are statically defined throughout the codebase.

[lukehinds]

Nice, taking a look at this, what is the memory footprint like?

[blkt]

I'm sorry @lukehinds I missed your comment.
Memory footprint is arund ~450 MB, and the database i ~200 MB itself, so it's still manageable on any developer's machine.

[lukehinds]

@blkt I am happy to get this merged, but do you think we need the profiler active still or does that add somehow?

[blkt]

The profiler is only active if CODEGATE_PROFILE_<key> is defined in the process environment, so it can be merged without impact to the end user.

The only change visible to the user is in speed.