Refactor recording api methods and fix logic

Refactored code of recording api setup, teardown, and
endpoint functions.

Added a get_current_state_str() method to Multimedia to make some code
in recording api cleaner.

Fix to recording api logic determining next_id.
Fix to test_server.py teardown to undo patching to media_dict
I've been trying to figure out the best way to deal with the fact that our recording api needs to fire some code when our server stops. I don't think do_teardown_app context has the same functionality of what I'm trying to accomplish here. do_teardown_appcontext is a method that fires after the destruction of an app context, generally used by flask extensions to get information about the flask app, and then do_teardown_appcontext will fire when that appcontext teardown occurs. 

So... my idea is that we should design/implement this REST server so it doesn't require any sort of teardown. Basically, I think we should have a database in our REST server backend (sqlite3?) to store references to our videos instead of a txt file of JSON objects. That way we can write to this database periodically when necessary, and no teardown code would need to fire at all when the server stops running. I have a pretty good idea of how to implement this, and when the database calls should occur, and what the database should look like, so let me know if this is a good idea.