Use JSON for Controls protocol messages

[Castaglia]

The Controls support in ProFTPD uses protocol messages that are length-prefixed strings. Nice and simple. The length is expressed as an int, read from a (Unix domain) socket. While this works because both client (ftpdctl) and server (mod_ctrls) are on the same host, it is not necessarily the best design. Nor does this format allow for more complex expressions of relationships, e.g. tables, lists, or nested arrangements thereof.

Thus the proposal to use JSON as the protocol message format instead. There is still the issue of expressing the length of the JSON message (using a length prefix again, or simply rely on EOF on read?), as well as the loss of "streaminess" when reading/writing the protocol messages. However, neither of these concerns really afflict the Controls protocol right now. And moving to JSON would make other, future actions easier.

When JSON support is used (with a flag for using the old format?), it should be done in a backward-compatible way. If, for example, we assume that all JSON-formatted Controls messages are JSON objects, then the first character (a char, or byte) would be {, which is an int value of 125. There are currently no Control actions whose name is 125 (or greater) bytes. We could impose a maximum action length of e.g. 80 characters, and thus provided a good sentinel for knowing whether to treat the message as JSON or not. The server (mod_ctrls) must always respond using the format requested by the client, to preserve interoperability.

[Castaglia]

Keep in mind how many existing action handlers would also need to be updated to provide JSON.

[Castaglia]

In thinking about this more, I think that preserving backward compatibility may not be worth the effort; most sites that use Controls, ftpdctl will install a ProFTPD package that's all the same version. I may need to provide/implement a different set of Controls API functions for this JSON version, and make the existing API functions all return errors, just in case.

[Castaglia]

And for all of the existing action handlers, there should be a way to preserve their existing API, but format the messages using JSON. That is, the struct of the message on the wire shouldn't leak into the API such that existing action handlers have to change at all.