Tidy up offer crossing:

* Clarify use of cancel view in OfferCreate transactor
* Reduce OfferStream public interface
* Reduce severity of some developer-only logging from ERROR to DEBUG

src/ripple/app/tx/impl/CreateOffer.cpp

@@ -563,8 +563,7 @@ CreateOffer::applyGuts (ApplyView& view, ApplyView& view_cancel)
     //       sequence to determine the transaction. Why is the offer sequence
     //       number insufficient?
 
-    auto const sleCreator = view.peek (
-        keylet::account(account_));
+    auto const sleCreator = view.peek (keylet::account(account_));
 
     deprecatedWrongOwnerCount_ = sleCreator->getFieldU32(sfOwnerCount);
 
@@ -831,9 +830,12 @@ CreateOffer::doApply()
     // This is the ledger view that we work against. Transactions are applied
     // as we go on processing transactions.
     Sandbox view (&ctx_.view());
-    // This is a checkpoint with just the fees paid. If something goes wrong
-    // with this transaction, we roll back to this ledger.
+
+    // This is a ledger with just the fees paid and any unfunded or expired
+    // offers we encounter removed. It's used when handling Fill-or-Kill offers,
+    // if the order isn't going to be placed, to avoid wasting the work we did.
     Sandbox viewCancel (&ctx_.view());
+
     auto const result = applyGuts(view, viewCancel);
     if (result.second)
         view.apply(ctx_.rawView());