Fix serverSync to use apiProxy logic in the same way the clientSync does

[lxanders]

Formerly the serverSync method in syncer.js used the dataAdapter to request data from an api host. This is a problem as e.g. the x-forward-for header is only set in the apiProxy. The serverSync method should work the same way as the clientSync method which already uses the apiProxy.

We extracted the proxy request logic to a reusable method proxyRequest stored in the apiProxyMiddleware. Additionally we added the res object to the global app object in the same way the req object is already being added to it, to allow a custom apiProxy making use of the res object.

One additional advantage would be the decoupling of the dataAdapter from the syncer which e.g. makes it simple to implement support for multiple dataAdapters (e.g. for REST and for SOAP).

CC: @c089, @selaux, @lo1tuma

[spikebrehm]

This isn't strictly necessary because req and res have references to each other -- i.e. you could do this.app.req.res

[spikebrehm]

Thanks for pointing this out. I think it might make more sense to just move the X-Forwarded-For logic directly to the DataAdapter; it shouldn't really live on the middleware. That would simplify this a bit, yeah? What do you think?

[c089]

I'm with Spike on this one: We've been mixing responsibilities in the apiProxy a bit, which should only be concerned about proxying requests from the browser to the API.

I'm not sure if moving to DataAdapter is the best way though. We seem to be missing an extension point that would work for all requests (regardless of the environment they originated from) but is no in the DataAdapter. As I think in the long term we want to support separate DataAdapters (configurable per API, there's a ticket somewhere I think) -> that would require adding things like the x-forwarded-for thing to all of them...

[lxanders]

After discussing with c089 I'm with you now. The problem itself is still valid though so I'm not closing the pull request for now (it would have been a good idea to describe the problem in an issue and have the discussion there - next time).