It's fantastic that you asked this now, as I have just implemented it in SharePoint myself. This hinges on you having SharePoint designer, however.
In InfoPath, I created a text field called task status, promoted it to SharePoint with the ability to be modified. Now, Include some buttons on the form itself that say Approve or Reject. On button click, add a rule that changes Task Status to some identifiable string of text, like "Approved".
Now, in your workflow, (assuming you have SharePoint designer) before your task, set Task Status to equal Null. Within your task, create an action to wait for Task Status to not equal Null. After this wait condition, you can create an if-else chain of what Task Status may equal (ex: approved, rejected, request change). After this if-else chain, you must write an action end task process, so that the task will exit itself, since you are not directly interfacing with the task.
Essentially, what this does is wait for your InfoPath form to make a change to the promoted Task Status field, and then the workflow acts on this change.
The only downside to this so far that I've found is that SharePoint will automatically set the outcome of the task as "Cancelled", so you may want to collect the actual status of the task with a workflow variable. In addition, waiting for a field change is much slower than having someone hit an approve button directly interfaced with SharePoint. If time is of the essence, I would suggest sticking with the clunky two-phase process of InfoPath and SharePoint.