anchor.diff:  * <p>
   * <strong>The algorithm for all type of buckets is following:</strong>
   * <ul>
  -*     <li>Implementation issues asynchronous request to back-end behind the bucket(for local bucket it is just a synchronous call) in way which specific for each particular back-end.</li>
  +*     <li>Implementation issues asynchronous request to back-end behind the bucket(for local bucket it is just a synchronous call) in a way which specific for each particular back-end.</li>
   *     <li>Then uncompleted future returned to the caller.</li>
   *     <li>If back-end provides signal(through callback) that asynchronous request failed, then future completed exceptionally.</li>
   *     <li>When back-end provides signal(through callback) that request is done(for local bucket response got immediately), then following post-processing rules will be applied:
   *          <ul>
   *              <li>
  -*                  If tokens were consumed then future immediately completed by <tt>true</tt>.
  +*                  If tokens were consumed then the future immediately completed by <tt>true</tt>.
   *              </li>
   *              <li>
  -*                  If tokens were not consumed because were not enough tokens in the bucket and <tt>maxWaitNanos</tt> nanoseconds is not enough time to refill deficit,
  -*                  then future immediately completed by <tt>false</tt>.
  +*                  If tokens were not consumed because were not enough tokens in the bucket and <tt>maxWaitNanos</tt> nanoseconds is not enough time to refill the deficit,
  +*                  then the future is immediately completed by <tt>false</tt>.
   *              </li>
   *              <li>
   *                  If tokens were reserved(effectively consumed) then <tt>task</tt> to delayed completion will be scheduled to the <tt>scheduler</tt> via {@link ScheduledExecutorService#schedule(Runnable, long, TimeUnit)},
  -*                  when delay equals to time required to refill the deficit of tokens. After scheduler executes task the future completed by <tt>true</tt>.
  +*                  when delay equals to the time required to refill the deficit of tokens. After the scheduler executes the task the future completed by <tt>true</tt>.
   *              </li>
   *          </ul>
   *     </li>
   * </ul>
  -* It is strongly not recommended to do any heavy work in thread which completes the future,
  +* It is strongly not recommended to do any heavy work in a thread which completes the future,
   * because typically this will be a back-end thread which handles NIO selectors,
   * blocking this thread will take negative performance effect to back-end throughput,
   * so you always should resume control flow in another executor via methods like {@link CompletableFuture#thenApplyAsync(Function, Executor)}.
  
positive.code:      * Replaces configuration of this bucket.
       *
       * <p>
       * The first hard problem of configuration replacement is making decision how to propagate available tokens from bucket with previous configuration to bucket with new configuration.
       * If you don't care about previous bucket state then use {@link TokensInheritanceStrategy#RESET}.
       * But it becomes to a tricky problem when we expect that previous consumption(that has not been compensated by refill yet) should take effect to the bucket with new configuration.
       * In this case you need to make a choice between {@link TokensInheritanceStrategy#PROPORTIONALLY} and {@link TokensInheritanceStrategy#AS_IS}, read documentation about both with strong attention.
       *
       * <p> There is another problem when you are choosing {@link TokensInheritanceStrategy#PROPORTIONALLY} and {@link TokensInheritanceStrategy#AS_IS} and bucket has more then one bandwidth.
       * For example how does replaceConfiguration implementation should bind bandwidths to each other in the following example?
       * <pre>
       * <code>
       *     Bucket bucket = Bucket.builder()
  
negative.code: [source, java]
  ----
      /**
       * Returns a new copy of this bucket instance decorated by {@code listener}.
       * The created bucket will share the same tokens with the source bucket and vice versa.
       *
       * See javadocs for {@link BucketListener} in order to understand the semantics of listener.
       *
       * @param listener the listener of bucket events.
       *
  