Some user record providers might want to implement case-insensitive user
record matching, or other forms of non-normalized matching. So far
uderdb didn't allow that, because client's typically revalidate the
returned user records against the search keys (at least our clients do)
– they check if the search user name is actually part of the user record
and its aliases.
In order to support such lookups we thus need to allow the looup keys to
be part of the user record, but also not be persisted in it, because
the number of casings/spellings of a username might be ridiculously
high.
A nice way out is to allow "aliases" not only in the main part of the
record, but also in the "status" part, that contains information
dynamically determined at query time. We can insert a second "aliases"
field there, which the parser will then merge with the primary "aliases"
field, but the existing rules around "status" ensure tha the data is
never persisted.
Follow-up: e2e1f38f5a
170d7d49f5
