mod_proxy_http incorrectly requires continue response after already sending response data

mod_proxy_http always requires a continue response from the back end for a proxied POST. This is incorrect when it has already sent response data. The RFC7231 related to HTTP1.1 section 5.1.1 states:

A server MAY omit sending a 100 (Continue) response if it has
      already received some or all of the message body for the
      corresponding request, or if the framing indicates that there is
      no message body

So then mod_proxy_http sends the Expect header along with the request body and then waits for the 100-continue, which could be an issue if the backend chooses to omit it per the spec above. That can lead to POST requests hitting the ping timeout undesirably.

This was never a concern with EAP 6/JBossWeb since it always sent the 100-continue regardless. But currently, EAP 7/Undertow chooses to omit it in this scenario, which causes request failures and error states from ping timeouts. This also impacts mod_cluster if proxying over http.

If mod_proxy_http is always going to require a 100-continue response, then we have to ensure it doesn't send the request body before that response. Or it may be helpful to provide some other means of disabling this POST 100-continue ping besides force-proxy-request-1.0.