adjust storage folder constants

To my surprise, there are actually users complaining about the fact that they are not allowed to have storage folders that are 500 TiB large. Unfortunately, due to inherent compromises made by the design, 32 PiB is the largest storage folder that the contract manager can handle.

If you are going to allocate a 32 PiB storage folder, then it's going to happen over the course of a very large number of file.Truncate calls. Originally the truncate calls grew the folder 50 MB at a time. Now they grow the folder 32GB at a time, which means only 1 << 20 (about a million) calls the Truncate will be needed when allocating a 32 PiB storage folder. That operation could still take several days to complete, but it's a tradeoff against filesystems that don't support sparse files, and therefore would be unable to show meaningful progress to users except for giant jumps greater than 32 GB at a time.

I'm sure someone will complain about how long it takes to allocate a 32 PiB storage folder. I'm sure that we'll also see complaints that they want much larger storage folders than that.

Oh well. We'll deal with it when it happens.