Add Django connection pools feature

[obulat]

Description

Adding connection pools to fix the memory leak and improve the db connections.

Some tests were fixed by adding (transaction=True) to @pytest.mark.django_db.
Somehow, the handling of the database in unit tests was interfering with the real database in the integration tests, because without the transaction settings on the unit tests that were handling user/throttled_app tables, the integration auth test was failing. I think the rolling back of the database that happens with the default setting (transaction=False) was interfering with the main database.

To minimize the interaction between the unit test mock database and the integration tests database, I added a just api/test-ci script that runs unit tests before running the integration tests.

There were two tests that were marked as skipped, as well as all tests for the examples.
@krysal, @dhruvkb, do you think it's okay to skip the tests and try this feature in prod? Or should we try to get all of the tests to pass (in that case, we should probably have in sync session for it because I don't know how to fix the last tests).

Testing Instructions

The CI should pass and the number of db connections should not keep increasing in production after the release.

Checklist

• My pull request has a descriptive title (not a vague title likeUpdate index.md).
• My pull request targets the default branch of the repository (main) or a parent feature branch.
• My commit messages follow best practices.
• My code follows the established code style of the repository.
• I added or updated tests for the changes I made (if applicable).
• I added or updated documentation (if applicable).
• I tried running the project locally and verified that there are no visible errors.
• I ran the DAG documentation generator (ov just catalog/generate-docs for catalog
  PRs) or the media properties generator (ov just catalog/generate-docs media-props
  for the catalog or ov just api/generate-docs for the API) where applicable.

Developer Certificate of Origin

Developer Certificate of Origin

Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.


Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.

[github-actions]

Latest k6 run output¹

     ✓ status was 200

     checks.........................: 100.00% ✓ 408      ✗ 0   
     data_received..................: 96 MB   399 kB/s
     data_sent......................: 53 kB   221 B/s
     http_req_blocked...............: avg=56.85µs  min=2.37µs   med=4.51µs   max=1.42ms   p(90)=146.44µs p(95)=207.88µs
     http_req_connecting............: avg=38.15µs  min=0s       med=0s       max=1.38ms   p(90)=98.83µs  p(95)=134.09µs
     http_req_duration..............: avg=156.51ms min=15.74ms  med=97.59ms  max=982.32ms p(90)=372.46ms p(95)=473.51ms
       { expected_response:true }...: avg=156.51ms min=15.74ms  med=97.59ms  max=982.32ms p(90)=372.46ms p(95)=473.51ms
   ✓ http_req_failed................: 0.00%   ✓ 0        ✗ 408 
     http_req_receiving.............: avg=155.15µs min=42.09µs  med=124.8µs  max=1.12ms   p(90)=247.49µs p(95)=332.68µs
     http_req_sending...............: avg=24.67µs  min=7.71µs   med=21.62µs  max=394.4µs  p(90)=35.46µs  p(95)=43.17µs 
     http_req_tls_handshaking.......: avg=0s       min=0s       med=0s       max=0s       p(90)=0s       p(95)=0s      
     http_req_waiting...............: avg=156.33ms min=15.66ms  med=97.47ms  max=981.98ms p(90)=372.27ms p(95)=473.27ms
     http_reqs......................: 408     1.694259/s
     iteration_duration.............: avg=847.12ms min=277.82ms med=858.67ms max=1.77s    p(90)=1.15s    p(95)=1.52s   
     iterations.....................: 76      0.315597/s
     vus............................: 2       min=0      max=6 
     vus_max........................: 60      min=60     max=60

Footnotes

1. This comment will automatically update with new output each time k6 runs for this PR ↩

[dhruvkb]

This is great! It's truly wild that the two kinds of tests were mutually interfering and we hadn't caught this so far.

[dhruvkb]

Small nit: a single-line comment here would be preferable as this will be shown when running just with no arguments. The long one can be inside the recipe.