Combine "playback_times" and "watching_now" tables into "playback_history" table

[tjenkinson]

Currently there is a "playback_times" table and "watching_now" table.

These should be combined into a single "playback_history" table which will store user session ids.

Each record will have a boolean which indicates whether the video was playing at the time the record was created, and a field which contains the number of seconds the user was into the video when the record was created, as well as a field containing the media item id that the person is watching.

There should be a session_id field which has a constraint to the sessions table and is set to NULL when the session is removed, and also a original_session_id which has no constraints and is set to the same value when the record is created.

When a users session expires the record should remain in the table along with the session id so that these records can then be used to generate statistics.

[tjenkinson]

https://github.com/LA1TV/Website/tree/feat-playback-history

[tjenkinson]

Complication because playback_times table stores times with the source vod file id not the media item id, because a video for a media item could be reuploaded and have been edited meaning previously stored times for the old version would no longer make sense. Also this mimics how the playback times are stored locally in the web browser for users that aren't logged in.

Also time updates are not sent for live streams, only vod, and both of these can belong to a single media item. Therefore it should be possible for the time field to be null if there is no time available, and also there should be a vod_source_file_id which will point to the vod source file if the entry maps to someone watching vod. It should revert to null if the source file record is removed, meaning a new version has been uploaded. This means if a new version is uploaded the old time information isn't lost, but the knowledge is still there that they may no longer represent the correct points in the video.

It should also be possible to easily determine what the view count is from this table with a simple query (and then the view_count fields from media_items_video and media_items_live_stream can be removed). Another field should be added to enable this called constitutes_as_view which would be set to true if the system decides that the record that is being created should increment the view counter.

This means the view count can be calculated with a simple query which counts the results of filtering the records by media_item_id where constitutes_as_view is true. Also this means if the algorithm that decides when a 'view' is changes in the future, it won't effect the view counts of media items at the time, only future views.

When this system is in place there is then the issue of where the initial current view counts would be stored. Instead of the view_count fields in media_items_video and media_items_live_stream being removed, they should be renamed to initial_view_count, which would default to 0 for new entries, and this should be added to the view counts calculated with the new method.

[tjenkinson]

There also needs to be a type field which can be "vod" or "live" and represents what the record corresponds to.

[tjenkinson]

#587
#588