anchor.diff:  = Time Routed Aliases
   
   Time Routed Aliases (TRAs) is a SolrCloud feature that manages an alias and a time sequential series of collections.
  +
   It automatically creates new collections and (optionally) deletes old ones as it routes documents to the correct
     collection based on its timestamp.
   This approach allows for indefinite indexing of data without degradation of performance otherwise experienced due to the
     continuous growth of a single index.
  +
   If you need to store a lot of timestamped data in Solr, such as logs or IoT sensor data, then this feature probably
     makes more sense than creating one sharded hash-routed collection.
   
  -== How it works
  +== How It Works
   
   First you create a time routed aliases using the <<collections-api.adoc#createalias,CREATEALIAS>> command with some
     router settings.
   Most of the settings are editable at a later time using the <<collections-api.adoc#aliasprop,ALIASPROP>> command.
  +
   The first collection will be created automatically, along with an alias pointing to it.
   Each underlying Solr "core" in a collection that is a member of a TRA has a special core property referencing the alias.
   The name of each collection is comprised of the TRA name and the start timestamp (UTC), with trailing zeros and symbols
  
positive.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 at 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:
  
negative.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
  