feat(tests): add populated_db_template and update read_only_db fixture

[omkute10]

Description

• Added populated_db_template and populated_db fixtures to enhance testing capabilities
• Updated read_only_db fixture to use the new populated database template
• Improved test database setup with sample data for more realistic testing scenarios

This PR implements a TODO in conftest.py to add populated database fixtures, making the test environment more robust and useful for testing database interactions.

Notes for Reviewers

• The new fixtures follow the same pattern as existing ones
• Added sample test data (a test user) with comments for easy extension
• Includes proper cleanup of test resources
• The changes are backward compatible with existing tests

Signed commits

• [x] Yes, I signed my commits.

[MoralCode]

thanks for this PR! This is also something ive been working on (updating test fixtures to allow a test database to be spun up/set up)

One of the challenges is that we have several ways to initialize the schema and they are all different.

• the .sql file you use here is pretty static/independent, likely somewhat dated, and also failed to work when i messed with it as part of my testing (the way it populates data from stdin seemed to be failing)
• replaying the schema migrations (what the Augur CLI does) seems to be the main way, but it requires building augur enough to access alembic and stuff
• creating the schemas from the SQLAlchemy models seem to me missing/not creating some required sequences, making it hard to inititalize things

I want to get these all in sync so that this testing is less fragile in future

[MoralCode]

So are you looking forward to work on this issue or should I carry forward with the improvements?

I will likely be implementing something very similar to this based on my own branch, which makes some more fundamental changes to how the database is connected to and generally used in these test fixtures. That version is most likely the one that will end up getting merged.

Unless this is valuable to you personally (i.e. as a learning project/for fun), I would encourage you find other ways to help out. If working on database stuff like this is something you are interested in, you can take a look at the db-testing branch (which contains my changes) and see if you notice how I'm doing things. You could also potentially work based on that branch if you'd like to propose specific commits; however, I realize I haven't communicated my plans in these areas too thoroughly and there's a high likelihood that I'm going to be moving fairly fast on this kind of thing.

That said, Once the v0.91.0 milestone is all merged and shipped, there will be some more functional (albeit basic/without database capabilities) unit testing capabilities in the repository, so if you wanted to poke around and try and write tests for some of the classes or other parts of the repo that could be one way to help (although maybe check in somewhere - ideally on slack - to make sure the parts of the code you are testing are parts we plan to keep around - theres a lot of jank in this codebase that Im hoping to clean up in the very near future so a lot of stuff is probably going to be changing)

[sgoggins]

@MoralCode : I think this one can be closed based on the last discussions.

[MoralCode]

I dont want to close it because it'll help remind me that i need to get around to doing this. The database test fixture stuff is largely waiting on #3435 right now because its going to be so much easier to initialize testing dbs with sqlalchemy than by replaying all past migrations. (and will act as a proof of concept for doing this as part of the main app's DB init process in future)