[See also T89177 and T102524 - may eventually merge those in as duplicates]
The driving factors here are:
1. We want to align the two on various analytics and functional header info related to X-Forwarded-For, X-Forwarded-By, X-CS, X-CS2, X-Analytics, etc. That and X-Subdomain are really the key functional differences in the VCL code of the two today (the other is Cookie handling).
2. One of the key reasons to leave mobile segregated in the past was its high potential fragmentation due to Vary-ing on X-CS for many different carriers in support of Zero. However, that was long ago addressed with the "X-CS: ON" -related work. Only a handful of special URLs now fully vary on a real carrier-id.
3. Mobile is currently under-utilizing a 4-node cache cluster at each site, when its traffic could easily now be merged into the text cluster in terms of load and hot dataset size, etc. Reducing the count of distinct cache clusters with independent complex configurations is a big complexity/maintenance win at various levels, and helps to further reduce the required minimum machine counts at cache datacenters to support all traffic reliably.
Some of the key steps and/or issues to address here (many can be done as slow refactor work leading up to the bigger switches):
[X] Align the current text and mobile VCL code better where they differ for trivial or non-existent reasons, or one (usually text!) is simply better-configured than the other.
[X] Re-evaluate mobile cookie handling and fix it (it's definitely not correct and has some workaround in the form of a global hash_ignore_busy, and also I don't really understand the disable/optin parts), and in the process align text/mobile on shared cookie code based on text-common.inc.vcl.erb with mobile mods.
[ ] Ensure that e.g. X-CS/X-F-B do not trigger anything unwanted in the desktop render path due to mobile assumptions.
[ ] Copy over and enable the extended analytics (X-CS, X-CS2, X-F-B, X-Analytics) in the text VCL
[ ] Ensure app aligns on how they handle related headers and output for text-vs-mobile - a critical issue here is that the applayer currently emits differing Vary headers for the same URL depending on whether it sees the mobile headers (X-Subdomain). Vary needs to be consistent from the applayer per-URL regardless of input headers. This allows the 3 page variants (Desktop, Mobile, and Zero) to share a cache without polluting each other.
[ ] Turn on the key mobile code in the text-caches with subdomain regexes protecting exclusive parts in both directions (e.g. current text's mobile redirect code, and mobile's X-Subdomain code).
[ ] Move the mobile IPs to the text-cluster. The two would still differ on IP address, but would both come through the same nginx proxy with the unified cert and same varnish instance with Vary on X-CS/X-Subdomain keeping the cache segregated.
As I understand it, currently Zero partners are only whitelist-differentiating on whether they whitelist images (upload), not on the distinction between desktop and mobile text IPs. This means if we get through all of the above and this assumption holds, we could also then update the mobile hostnames to use text's IPs. This would simplify other configuration, save space in the public service address blocks, and allow SPDY/HTTP2 coalesce during desktop->mobile redirects to boot. We could also, from this point forward, look at perhaps doing other more advanced and efficient things with the desktop/mobile split/redirect/rewrite stuff, but it's probably better to see how all of the above turns out before digging deeper on that.