Refactor audits/infraction events

[patrickklaeren]

I've been looking at the design of infractions (in particular, the auditing aspect, how we track what happens to audits) and it seems there's a bit of rigidity that doesn't allow for great amount of expansion. Infractions have grown to accommodate for more events and I believe the following proposal would both alleviate this issue of rigidity and provide a more streamlined approach to auditing.

Pseudo outline here:

Database models

public class Infraction
{
    public int Id { get; set; }
    public virtual ICollection<InfractionEvent> Events { get; set; }
}

public class InfractionEvent
{
    public int Id { get; set; }
    public InfractionEventType Type { get; set; }
    public DateTime AddedDateTime { get; set; }
    public int AddedByUserId { get; set; }
    public virtual User AddedByUser { get; set; }
}

An infraction will have one or many infraction events. InfractionEvent may take the form of:

public enum InfractionEvent
{
    Created,
    Updated,
    Rescinded,
    Deleted
}

I could see this easily being split out into a database driven member, but I believe there is not so much demand to make infraction events configurable.

We can retain the original created date/author on the Infraction model, but also add to the infraction events, so that it is easier to query.