mach-defpager/serverboot changes (tmpfs too)

[Roland McGrath]

I have just checked in changes that excise the default pager functionality
from serverboot.  The $(paging-file) et al boot script functions are still
recognized, but now just print a message telling you to use swapon.  The
magic "die $(serverboot)" line is ignored completely, and serverboot now
always exits immediately after processing the boot script.  I don't expect
that anyone is still using serverboot since we've had boot script support
in the kernel for a while now.  We'll probably nuke it entirely at some
point.  But as long as we still have it, someone please test that I haven't
broken it.  (Note that serverboot no longer groks the bootstrap RPCs.  But
the Hurd servers don't use those anyway.)

I removed a little cruft from mach-defpager too while I was at it.
Please make sure I didn't break it.

The meaty change I did at the same time was to add the
default_pager_object_set_size RPC to hurd/default_pager.defs and the
implementation of it to the default pager (mach-defpager).  (This doesn't
interact with any old code, so I should not have broken anything that
worked before--but it's always possible.)  This is the feature that tmpfs
needs to make truncating files work properly.  I've also changed tmpfs to
use the new call, though it acts as before when talking to a default pager
that does not understand it.

Please test the new code.  The easiest way to test the new default pager
code is just to use tmpfs.  What should now work properly:
1. create a tmpfs file and write exactly two pages into it
2. mmap at least three pages into memory 
3. verify you can read and write the first two pages (write nonzero data)
4. verify that you fault reading the third page
5. ftruncate that file to 1024 (i.e. less than one page)
6. verify that you fault when reading the second page
7. verify that you can still read and write the first 1024 bytes of the mapping
8. ftruncate that file back to a size >= two pages
9. verify that you can read the second page of the mapping and it's ALL ZEROS
10. verify that you can write into the second page of the mapping again 
11. close the file (end that process), and verify what you wrote is still there
(This needs to be the same process that called mmap just once in step 2
using that same mapping through step 10.)

Doing this with an old default pager (or an old tmpfs, which doesn't try to
use the new default pager feature) will not fault in step 4 or step 6, and
will still have the data from step 3 left over instead of zero-fill in step 9. 

With this, I think tmpfs should be functionally complete and correct.


Thanks,
Roland