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
Off by one error? Wouldn't `recording.next_id` end up being equal to the largest id?