Consider tightening `AuditEventRepository` contract

AuditEventRepository exposes 3 operations for retrieving AuditEvents:

• AuditEventRepository#find(java.util.Date)
• AuditEventRepository#find(java.lang.String, java.util.Date)
• AuditEventRepository#find(java.lang.String, java.util.Date, java.lang.String)

All of these operations allow their parameters to be null which IMO isn’t ideal, and is also somewhat confusing as all the retrieval options can actually be expressed using AuditEventRepository#find(java.lang.String, java.util.Date, java.lang.String).

Perhaps AuditEventRepository contract could be tightened so that it wouldn’t allow null parameters? This was actually proposed in #5854 as a part of improvements to AuditEventRepository however at the time the change wasn’t feasible due to backward compatibility considerations. The upcoming 2.0 could be the chance to revisit this.

It’s also worth noting that auditevents Endpoint already behaves inline with what’s proposed above as it requires the presence of after parameter.

[wilkinsona]

If we agree that after can be null, I’m not sure that the status quo is the ideal. I think we should consider either overloading the method with all possible combinations of the three parameters, or only offering a single find method that allows any of the parameters to be null. We currently seem to have an arbitrarily chosen set of overloads that leave us halfway between the two options.

[wilkinsona]

We’ve agreed to go with a single method that takes all three, possibly null parameters:

List<AuditEvent> find(String principal, Date after, String type)