IssueTracker

I'll be happy to implement this

I looked around the code and I found out that actual copying of the database file is done in SQLiteCopyOpenHelper - getWritableDatabase() and getReadableDatabase() methods are calling verifyDatabaseFile() which does the copying under the hoods.

My idea is to:
1. Add RoomDatabase.Callback#onPopulated method
2. SQLiteCopyOpenHelper already has access to a list of callbacks (List<RoomDatabase.Callback>) through mDatabaseConfiguration.callbacks
3. Modify getWritableDatabase() and getReadableDatabase() so that after the file is copied I can iterate over those callbacks and call onPopulated. I would pass mDelegate.getWritableDatabase() and mDelegate.getReadableDatabase() as a parameter to onPopulated.
4. Add tests in DatabaseCallbackTest

I asked Danny about it and he said that I might need to temporarily open the DB with a vanilla open helper just to invoke onPopulated close it and then let Room re-open it through the normal path. Not sure how would I do that yet so I'm still reading and trying to get better understanding of the code.

This probably also doesn't take this "transactionality" thing into account so I need to look into it. I think I'll try to create some tests that will help me verify if it works or not.

I'm also wondering if there is a way to build the lib locally so I can test it on a sample project. Can I somehow publish it to local maven or something?

1) We probably want a more descriptive name, maybe onPopulatedFromAssets or something like that.

For transactionality, we do actually have a table called `room_master_table` that we can use. I made a mistake on the design of that table by not having proper keys :facepalm: instead it only has 1 id column. It is possible to create a migration for it within room but for this task, we can just add another magic number (we use 42 for identity hash) to check if we did successfully call onPopuplated (and also, we need to call on populated as we propbably don't want to call it if it is not created from assets).

For testing, TestApp is probably sufficient.

If you want to build a maven repo, you can execute:

```
cd room && DIST_DIR=$(pwd)/../repo ./gradlew createDiffArchiveForAndroidxRoom
```

This is a special task that checks the versions in maven.google.com and creates a zip with artifacts that do not exist in there (you may need to bump the LibrrayVersion).

Thanks!
When it comes to naming, I was considering onPopulatedFromAssets but there is also createFromFile method in Room database builder so I think we should use something more generic. What do you think?