anchor.diff:  
   * Only *time* routed aliases are supported.  If you instead have some other sequential number, you could fake it
     as a time (e.g., convert to a timestamp assuming some epoch and increment).
  -  The smallest possible interval is one second.
  -  No other routing scheme is supported, although this feature was developed with considerations that it could be
  ++
  +The smallest possible interval is one second.
  +No other routing scheme is supported, although this feature was developed with considerations that it could be
     extended/improved to other schemes.
   
   * The underlying collections form a contiguous sequence without gaps.  This will not be suitable when there are
  
positive.code:   added at the front of the TRA.
    TRUP will create this collection, add it to the alias and then forward the document to the collection it just created.
    This can happen recursively if more than one collection needs to be created.
    Each time a new collection is added, the oldest collections in the TRA are examined for possible deletion, if that has
      been configured.
    All this happens synchronously, potentially adding seconds to the update request and indexing latency.
  
  Any other type of update like a commit or delete is routed by TRUP to all collections.
  Generally speaking, this is not a performance concern. When Solr receives a delete or commit wherein nothing is deleted
  
negative.code: 
  When adding data, you should usually direct documents to the alias (e.g., reference the alias name instead of any collection).
  The Solr server and CloudSolrClient will direct an update request to the first collection that an alias points to.
  
  The collections list for a TRA is always reverse sorted, and thus the connection path of the request will route to the
    lead collection. Using CloudSolrClient is preferable as it can reduce the number of underlying physical HTTP requests by one.
  If you know that a particular set of documents to be delivered is going to a particular older collection then you could
    direct it there from the client side as an optimization but it's not necessary. CloudSolrClient does not (yet) do this.
  
  When processing an update for a TRA, Solr initializes its
    <<update-request-processors.adoc#update-request-processors,UpdateRequestProcessor>> chain as usual, but
    when `DistributedUpdateProcessor` (DUP) initializes, it detects that the update targets a TRA and injects
    `TimeRoutedUpdateProcessor` (TRUP) in front of itself.
  TRUP, in coordination with the Overseer, is the main part of a TRA, and must immediately precede DUP. It is not
    possible to configure custom chains with other types of UpdateRequestProcessors between TRUP and DUP.
  
  TRUP first reads TRA configuration from the alias properties when it is initialized.  As it sees each document, it checks for
    changes to TRA properties, updates its cached configuration if needed and then determines which collection the
    document belongs to:
  