The 'draft' state in the {Sms,Mms}Message doesn't make sense. #83
Description
From the implementation of point of view, I think the 'draft' state is infeasible because we don't have any APIs to save the drafts.
Even if we have one, we still need to extend the current send(...) to be able to resend a draft (by ID) that has already saved in the back-end DB. Otherwise, the content side needs to retrieve the draft from DB, delete it from DB and then call send(...) again to send the message as if sending a new one. In either ways, you can imagine there are lots of extra work we need to change the APIs and the way of using them just to make it deal with drafting, which sounds a bad idea to me.
I'd suggest let's remove the 'draft' state from the {Sms,Mms}Message and implement the drafting things on the content side. That is, the messaging app should be in charge of maintaining a DB to manage the drafts.
Moreover, drafting sounds more like an app-specific feature to me, we should stop handling drafts in the back-end DB. Eventually, the back-end DB should only deal with the messages that need to be shared with other apps through the DataStore APIs.