Feature flags for new controller-accessible Tor features
As Tor grows new features available via the control protocol, it would be useful to indicate support for these features via some GETINFO.
Currently, controllers have two ways to discover if the Tor they connected to supports a feature: "just try" and see if there's an error; or look at the Tor version.
Both of these can be problematic:
You can't always "just try". For example, when HS_DESC was first added as an event it didn't include the onion address, so you'd wait forever to see if a descriptor was uploaded. For completely new commands, "just try" is probably sufficient but when commands gain new capabilities and/or options it can get less obvious what the right thing to do is.
Doing version comparisons can get tricky: as a new feature is implemented, it will generally appear on master first, then maybe in an alpha release and finally in a "real/full" release. A controller wanting to take fullest advantage of a new feature (e.g. to let users test it against a Tor from "master") would have to program in each of these versions separately, which is tedious.
Instead, a definitive "GETINFO" which returns details of the feature would be ideal. Then, a controller can change its behavior and take advantage of a new feature as soon as it's on master and users can continue to take advantage of this as the feature moves through alphas, betas, etcetera. This would also work well for features that can be turned off (or on) through other mechanisms (e.g. configuration, command-line or build options).
Such flags could also "roll up" logical features that actually need multiple controller commands/events to work. For example, adding v3 services changed some config options, modified the ADD_ONION command and (later) provided upload information via the HS_DESC event. So until the ADD_ONION and HS_DESC changes landed, a controller couldn't properly add a v3 ephemeral service.