outgoing-handler and valid request-options

Presently, we have a record request-options full of optional timeout values, which is accepted as a parameter by outgoing-handler.handle. The three timeouts are for making the connection, first byte, and between bytes.

Some implementations, such as one implemented using Web fetch, will be not able to implement these timeouts faithfully. Should we specify that, if the options cannot be satisfied, these handlers return an error from handle? If so, we need an error variant, or some different error enum, that will report this properly.

One alternative in this design space is to make request-options a resource declared in the outgoing-handler interface. It can have a constructor taking no arguments named default, and for each timeout currently in the record, make a getter method that returns option, and a setter method that takes option and returns result. This allows the interface to deny an individual field. It also leaves the door open to worlds that can offer additional request options (e.g. enforce TLS, client certificates) the ability to add more setters and getters of the request-options type as standalone functions.

Review the outgoing-handler.handle interface and the request-options record, focusing on the connection, first-byte, and between-bytes timeouts. Compare the proposed error variant with making request-options a resource whose setters can reject values. Done means the interface behavior and error or resource design are specified and agreed upon.