Supporting custom date formats when resolving a tsdb data stream to a backing index makes the logic on the coordinating node complicated, because the target backing index is unknown. It is only known after parsing the `@timestamp` field, but in order to parse the timestamp field the date format should be known and this information is stored in the mapping of a backing index.

In order to avoid unnecessary complexity when coordinating a bulk request we need to make the following changes:

- Only support `strict_date_optional_time` and `strict_date_optional_time_nanos` date formats for the `@timestamp` field in tsdb data streams. For now we don't expect that we need to support other date formats. In order to do this we also need to prohibit field mapping for the `@timestamp` field that allow any other date format for backing indices of tsdb data streams.
- When resolving the backing index for tsdb data streams on the coordinating node, truncate millisecond and nanosecond precision from the the timestamp only for determining to what backing index the document should be indexed into. Also the `DataStreamIndexSettingsProvider` should be adjusted to truncate ms/ns precision when setting the `index.time_series.start_time` and `index.time_series.end_time` index settings. Note that, on the data node when documents get indexed the timestamp do get parsed into a date value that confirms with the field mapping of the `@timestamp` field.

Note that currently only `strict_date_optional_time` and ms since epoch provided as long is supported for tsdb data streams (see this [TODO](https://github.com/elastic/elasticsearch/blob/master/server/src/main/java/org/elasticsearch/cluster/metadata/IndexAbstraction.java#L459)). 
server/src/main/java/org/elasticsearch/cluster/metadata/IndexAbstraction.java
* An index abstraction is a reference to one or more concrete indices.
 * An index abstraction has a unique name and encapsulates all the  {@link IndexMetadata} instances it is pointing to.
 * Also depending on type it may refer to a single or many concrete indices and may or may not have a write index.
 */
public interface IndexAbstraction {
    /**
     * @return the type of the index abstraction
     */
    Type getType();
    /**
     * @return the name of the index abstraction
     */
    String getName();
    /**
     * @return All {@link IndexMetadata} of all concrete indices this index abstraction is referring to.
     */
    List<Index> getIndices();
    /**
     * A write index is a dedicated concrete index, that accepts all the new documents that belong to an index abstraction.
     * <p>
     * A write index may also be a regular concrete index of a index abstraction and may therefore also be returned
     * by {@link #getIndices()}. An index abstraction may also not have a dedicated write index.
     *
     * @return the write index of this index abstraction or
     * <code>null</code> if this index abstraction doesn't have a write index.
     */
    @Nullable
    Index getWriteIndex();
    default Index getWriteIndex(IndexRequest request, Metadata metadata) {
        return getWriteIndex();