[tahoe-lafs-trac-stream] [Tahoe-LAFS] #3849: Refactor Foolscap code so it's separate from non-Foolscap code in storage API

[Tahoe-LAFS]

#3849: Refactor Foolscap code so it's separate from non-Foolscap code in storage
API
----------------------+---------------------------------------
 Reporter:  itamarst  |          Owner:  itamarst
     Type:  task      |         Status:  new
 Priority:  normal    |      Milestone:  HTTP Storage Protocol
Component:  unknown   |        Version:  n/a
 Keywords:            |  Launchpad Bug:
----------------------+---------------------------------------
 Right now Foolscap implementation is heavily tied in to StorageServer,
 BucketWriter, and BucketReader. Sometimes the business logic is separate
 method, sometimes not.

 This means it's harder to see which parts are Foolscap-specific, it's
 harder to make the type checker happy due to `RIStorageServer` interfaces
 and friends (which specify `foo()` but need `remote_foo()`), and it makes
 ripping out Foolscap later on harder.

 So, much like HTTP is a separate class wrapping the underlying
 StorageServer, Foolscap should also be separate classes wrapping the
 underlying StorageServer etc..

--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/3849>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage