spec: Clarify STARTTLS vs. STRUCTURED_REPLY

spec: Clarify STARTTLS vs. STRUCTURED_REPLY

Consider a SELECTIVETLS server and a MitM attacker, under the
following NBD_OPT_ handshake scenario:

 client:                  mitm:                    server:
 > _STARTTLS
                          > _STRUCTURED_REPLY
                                                   < _REP_ACK
                          > _STARTTLS
                                                   < _REP_ACK
                          < _REP_ACK
 > _GO
                          > _GO
                                                   < _REP_ACK
                          < _REP_ACK
 > NBD_CMD_READ

In this scenario, the client is NOT expecting structured replies from
the server, but if the server feels obligated to send them based on
the plaintext negotiation, it may confuse the client.  The MitM
attacker was thus able to corrupt the connection, even without having
any encryption keys.  The only sane approach is to forbid ALL stateful
negotiations from having any effect post-encryption (the MitM's
injected packet is effectively ignored, and the client proceeds
without structured replies).

Unfortunately, nbdkit 1.26.0 is buggy in this regards - a CVE will be
opened against that product.  nbd-server does not yet understand
NBD_OPT_STRUCTURED_REPLY, and qemu as server does not use SELECTIVETLS
mode, so they are immune.