Follows-up Idb5b0d21adc6. Avoid hardcoded references to REST internal
configuration variables, which create awkward "APIs" in the long run.
These are hard to deprecate or detect use of, and even harder to
normalize/support once variations exist. E.g. in T189966 and T233886,
I've been working to remove the concept of dynamic config in favour of
the uncomputed values being only valid as configuration for the
component that owns the variable, instead of using Config as public
API to read non-normalized information that belongs to a different
component.
By making the recipient responsible for any dynamic computation, it
also becomes clear that these are in fact not normalized or validated,
which can expose any number of unpredictable behaviours if used
directly. Consider special values like `false` or `null` and the
responsibility for interpreting that. Accessing these from a stable
function also gives a natural place for deprecation to happen. The
alternative, is for dynamic computation to happen in Setup.php for
all variabls, and only ever grow and become an append-only dumping
ground for every thing that we feel at some point needs validation,
normalization or expansion, which doesn't scale well, hence I reversed
this trend in T189966/T233886.
As it happens, RestPath actually is already computed, albeit very
trivially. This patch opens the way for someone to remove that in
favour of PathRouter accept `false` directly and expanding (and testing)
that code there instead.
As for REST API, the only stable and universally supported entrypoint
is /w/rest.php. Unlike some older entry points, we don't support
moving or removing the rest.php file. We do support routing/aliasing
additional paths to it.
Change-Id: I589a8aed8db3b8e7b72e4505749bb7ef25a755d9
217d47d46e