Improve broadcaster's HTTP push api protocol

Nobody has claimed this yet.

**Is your feature request related to a problem? Please describe.**

Currently, B returns HTTP 200 OK only after the transcoding process is completed. This results in the need for having a high timeout on the client-side.

**Describe the solution you'd like**

Two ideas for improvements:
1. B can return HTTP 200 OK header as soon as the segment is uploaded, then return the transcoded data in the response body (make B protocol the same as how B<>O protocol behaves).
2. Make B HTTP 200 OK protocol async.

Some comments from #2113 made by @victorges:
> - Make the mist <> B protocol similar to B <> O, replying with 200 as soon as request body upload finishes. I am not sure what benefits this would bring apart from the consistency, but I think that is enough reason to do it if you think it's worth.
> - Address any issues with the B<>O protocol (and potentially mist <> B). Doesn't seem like a big priority since we'll be moving to streaming anyway, but could be a nice to have depending on which protocols/tools we'd like to be compliant to.

**Describe alternatives you've considered**
N/A

**Additional context**
N/A

No files or tests are named. Start by locating the broadcaster's HTTP push API entry point and comparing its response timing with the B<>O protocol; clarify which of the two proposed behaviors is wanted, then define completion around an agreed protocol and corresponding tests.

Written by the indexing model from the issue text.