This PR enables RESTBase to communicate with both Parsoid/JS and Parsoid/PHP and use separate storage for each of them. It introduces three sys modules: parsoid-js, parsoid-php and parsoid, which handle the JS variant, PHP variant and the main Parsoid module acting as the proxy, respectively.

The common Parsoid business logic has been extracted into lib/parsoid.js, while sys/parsoid-js and sys/parsoid-php only deal with variant-specific details: issuing requests to Parsoid and determining the buckets to use when storing/retrieving content. This code extraction and reshuffling was done for the following reasons:

• to have a clean separation between Parsoid/JS and Parsoid/PHP;
• to allow for their interchangeability, so that in case of problems it is easy to revert to having only one of them active;
• to have a clean code situation once the transition has been completed; and
• to avoid introducing any new permanent config parameters that are not used during the transition (i.e. users can choose to use one or the other without needing to adjust the config).

The proxy allows directing requests to either variant. It loads both variants' modules internally and uses their operations to complete requests. It is designed in such a way so as to allow an easy transition between fully using JS to fully using PHP with no config changes. When first introduced, its defaults emulate the JS-only scenario. Once the switch is fully achieved, then simply changing sys/parsoid.js for sys/parsoid-php.js in projects/sys/default.wmf.yaml with no config change results in having a fully-functional Parsoid/PHP module. The proxy can. thus, function properly with only one of variant modules loaded and configured.

In order to support the transition period, the proxy has three modes of operation: single, mirror and split. In single mode, only one variant is used, defined by the default_variant configuration value, defaulting to js. This allows us to start using the proxy with no config changes. In the final stages of the transition (before we remove the proxy), it can be changed to php to only use the PHP variant. The mirror mode is used to asynchronously mirror traffic to the PHP variant. Requests are issued to both variants, but only the JS one is returned. The amount of traffic to be mirrored can be tuned with the percentage configuration parameter. The important caveat here is that only requests for /page/{format} end points are mirrored - we cannot do so reliably for transforms since they rely on stashed content, which is likely not to be available for the PHP variant. Furthermore, when the proxy is configured in mirror mode, dependency update events are emitted only for the JS variant, so as to avoid duplicates. Finally, the split mode is used to split the traffic between the two variants based on the request domain. If one of the patterns given in the pattern configuration parameter is matched, then the variant not defined in default_variant is used, otherwise the default one is used. This mode supports the second stage of the transition, where JS will be authoritative for the majority of domains, while we will be slowly moving projects one by one (or group by group) over to using Parsoid/PHP. Because of this gradual switch, there is also a built-in fall-back for transform end points in this mode: if a request for the non-default variant 404s, then we retry the request using the default variant in order to cover the clients that are in the middle of an editing session during the switch.

Apart from these modes, the proxy also supports clients directly telling it which variant to use. If the incoming request has the PARSOID_VARIANT cookie or the X-Parsoid-Variant header set, then the request is sent directly to that variant regardless of the proxy's mode. When deciding where to send the request, the proxy gives precedence to the header in case both are set.

Bug: T230791