This will transform each notification in a job to a row in a file.
The file is then uploaded to S3.
The files will later be aggregated by the notifications-ftp app to send to dvla.
The method to upload the file to S3 should be pulled into notifications-utils package.
It is the same method used in notifications-admin.
the `to` field stores either the phone number or the email address
of the recipient - it's a bit more complicated for letters, since
there are address lines 1 through 6, and a postcode. In utils, they're
stored alongside the personalisation, and we have to ensure that when
we persist to the database we keep as much parity with utils to make
our work easier. Aside from sending, the `to` field is also used to
show recipients on the front end report pages - we've decided that the
best thing to store here is address_line_1 - which is probably going to
be either a person's name, company name, or PO box number
Also, a lot of tests and test cleanup - I added create_template and
create_notification functions in db.py, so if you're creating new
fixtures you can use these functions, and you won't need to pass
notify_db and notify_db_session around, huzzah!
also removed create param from sample_notification since it's not used
anywhere
while it's nice to use the decorator to signify fixtures with side
effects, it has unfortunate problems of completely overriding any
fixtures you've declared in the funcargs - so isn't really suitable
for our usecase where we often have other fixtures we rely on to
return values to us.
So for consistency, let's remove this and stick to using funcargs
to define our fixtures
this create_user function can be imported for use in creating specific
users in your tests, for example
```
from tests.app.db import create_user
def test_create_user_persists_to_database(notify_db_session):
user = create_user()
assert User.query.count() == 1
```
this has the benefit of not requiring you to pass the notify_db and
notify_db_session fixtures around, and separating custom object
creation from the fixture dependency trees to aid clarity
I started with sample_user since it has no downstream dependencies, but
the intention is to push this out to all db fixtures eventually. This
is a total conversion, but can be rolled out in a non-breaking manner
by keeping arguments in the fixture, and passing them through to the
new db function - then tests can be updated to use the create_* instead
of sample_* functions as and when you want to
