Add support for custom indexes on events tables

[elexisvenator]

Adds 2 new methods to IEventStoreOptions:

• AddIndexToStreamsTable(IndexDefinition index)
• AddIndexToEventsTable(IndexDefinition index)

These do exactly what they say on the tin - the passed in index definition is added to the respective table. Adding custom indexes can be useful for doing maintenance queries, such as scanning for archived streams, looking for events by type, etc.

A test has been added to prove index generation works. Documentation with examples has also been added.

[oskardudycz]

Personally, I wouldn't like to provide the custom indexes enabled out of the box; I'd prefer to offer explicit toggles for the specific usage scenarios that we think are valid. Cases like stream type or archived are good, but custom indexes can be Pandora's box for cases where people will try to index their event data and think that we enabled it, as we are generally okay with that. Allowing such extended customisation creates many potential permutations on the support side. Having that said as: "you can use your custom SQL to index events table outside of Marten's auto-script", in that case, sounds fair enough to me.

So TLDR, I'm not against expanding our indexing capabilities, but I'd like to learn more about the exact usage scenarios and then enable them explicitly instead of the freehand way.

@jeremydmiller, thoughts?

[jeremydmiller]

@elexisvenator I'm going to agree with @oskardudycz.

Syntax wise though, if you want to fine tune the indexes, I'd rather we get closer to the document type syntax like:

        /// <summary>
        ///     Creates a computed index on this data member within the JSON data storage
        /// </summary>
        /// <param name="expression"></param>
        /// <param name="configure"></param>
        /// <returns></returns>
        public DocumentMappingExpression<T> Index(Expression<Func<T, object>> expression,
            Action<ComputedIndex>? configure = null)
        {
            _builder.Alter = m => m.Index(expression, configure);

            return this;
        }

But in this case we'd use IEvent as the T up there.

What indexes would you place on the streams table? That I think I'd rather have a bit more constrained.

I'll volunteer to get this across the finish line if you want since you've already done a lot here. The tests would still be useful.

[elexisvenator]

The specific use cases that I would like to support are:

• Stream>type, for maintenance queries (restreaming) that search based on the streams aggregate type
• Stream>archived, archiving happens mostly as a result of restreaming for us, there is a background job that searches for archived streams that were archived at least a week ago and deletes them.
• Event>type, for maintenance queries again, restreaming as well as a check to see if old events want to phase out still exist in the system
• Event>tenant, The primary key for a tenanted events table is event_id, tenant_id in that order. This is good for rapid lookup but doesnt help at all if you want to run queries over a specific tenant only. Having an index that is either tenant only or tenant and event in the opposite order would help a lot with this sort of query.

From a marten ecosystem perspective, i feel that the optional indexes you can add to documents should also be applicable to the events table, such as to the metadata and archived/soft deleted fields.

Happy to go into detail here or separately about what sort of maintenance/restreaming queries are going on in our system and why.