SFTP: put an approximation of grid capacity and available space in the 'df' output

[davidsarah]

Ticket #648 is about collecting server capacities and putting them on the welcome page. This might also allow a better approximation of available space than what SFTP currently outputs for 'df'.

Because the SFTP protocol did not originally have a way of implementing 'df', clients use either an extension (implemented at sftpd.py SftpUserHandler.extendedRequest) or try to log in to the server and issue a 'df' command (implemented in sftpd.py ShellSession.execCommand). sshfs does the latter, and will not mount the filesystem if it cannot do so. Currently we always report 314159265 KiB free, and double that capacity, to keep sshfs happy.

However, even given the space available on each server, it is not entirely obvious what to report as the total space available on the filesystem. Brian wrote in ticket #648:

Wait, what? What's the relationship between server-space available and the number that SFTP reports as available to any given client? Not trivial, I think.

If we do this, let's make it clear that we're providing only a very rough approximation of the client-side space. Adding together all of the raw server space and dividing by the expansion factor is pretty rough, especially with the servers-of-happiness change (e.g. one server has 14TB free, but you can't upload anything because everyone else is full: SFTP should announce 0).

Also let's make room for Accounting APIs to generate this data (since really it's a function of accounting: how much space an individual "user" is allowed to consume, which may be far less than the sum of all server capacities). At least let's be thinking in that direction when we name the functions.