Support GET on the /vtrack endpoint

[bretg]

We built the the /vtrack endpoint in #1015

The usage pattern is that Prebid.js users set this config:

pbjs.setConfig({
    cache: {
        url: "https://prebid-server.rubiconproject.com/vtrack?a=ACCOUNT",
        vasttrack: true
    }
});

Turns out there's a wrinkle where in the outstream scenario, Prebid.js is now using cache.url to retrieve the creative. This has been the case for a long time but I never noticed it until recently. The end result is that there are requests to /vtrack failing because they're GETs with &uuid= appended.

Changing Prebid.js is difficult, so the proposal is to change Prebid Server at least as an initial solution:

1. Allow the GET method on the /vtrack endpoint.
2. If it's called with a GET, then look for a uuid parameter. If there's no uuid, return 404.
3. If there's a ch parameter, this is a "cache host url". See Prebid Cache Cross Data Center Lookup #1620
   1. Parse to get the hostname out of the URL
   2. Validate the domain conforms to *.pbshostcompany.com. If it does, this is the host to use instead of that region's PBC.
4. If there is a uuid parameter, call PBC to retrieve that uuid.
5. If PBC returns successfully, forward the results to the client with HTTP 200.
6. If PBC returns with an error, forward that error to the client with the same HTTP code received from PBC.
7. log a metric vtrack.get.{success,error}.count
8. add the metric vtrack.post.{success,error}.count to the regular POST flow

[bretg]

Discussed in committee. There was concern that this may increase the prevalence of cross datacenter reads. In the end the prevalence of that scenario probably wouldn't increase as a result of this, but still, added the ch parameter discussed in #1620

[bsardo]

@bretg it's my understanding that this has been recently discussed in the CTV meeting. Have we made any progress on this?

[bretg]

Close - we discussed the GET endpoint in the CTV committee, not the /vtrack endpoint.

[bsardo]

Discussed in committee. Marking it as ready for dev. The committee doesn't have any concerns and the ch parameter addresses potential cross DC issues.