Fix event_type array query parsing

[svix-gabriel]

This fixes how ?event_types query parameters are parsed in */attempt/endpoint/*, in addition to some adjacent refactors.

Motivation

axum::Query doesn't support URL query array parameter parsing very well. For example,

• ?a=1&a=2 gets rejected
• ?a[]=1&a[]=2 also gets rejected
• ?a[0]=1&a[1]=2 also gets rejected

This is largely because serde::urlencoded doesn't support any of these formats. See nox/serde_urlencoded#75

There is serde_qs, which supports the last two. But not the first format. See samscott89/serde_qs#16

Unfortunately, we need to support the first format because that is what our internal API has supported up to today.

However, our OSS has been inconsistent. Specifically with ?event_types.

Most endpoints that took in ?event_types used MessageListFetchOptions, which manually parsed ?event_types only using the first format. Ideally, we'd like to support all 3.

In addition, */attempts/endpoint/ didn't use MessageListFetchOptions. Instead it relied on axum::Query deserialization, so ?event_types outright didn't work as expected with this endpoint.

Solution

This PR does a couple small things to fix these issues

1. MessageListFetchOptions is axed in favor of a more explicit EventTypesQuery. MessageListFetchOptions had an extra timestamp parameter, before, that is already parsed just fine by axum::Query.
2. EventTypesQuery is similar to MessageListFetchOptions, in respect to how event_types are parsed. With a few exceptions
   • EventTypesQuery validates the input.
   • EventTypesQuery handles all 3 formats, not just the first one
   • EventTypesQuery should be a bit more performant, since it uses form_urlencode, which parses pairs as Cow<str>, so fewer allocations. (Note that form_urlencode is what serde_urlencoded uses under the hood)
3. Updates */attempts/endpoint/ to use EventTypesQuery, so that ?event_types are parsed correctly. Tests are added to demonstrate and validate this behavior.