Currently, a stored filter contains all the values, for all the properties. If any property was not specified by the user, it is saved with the default value (eg, "any")
This produces a lot of useless data encoded in the filter array.

An inconvenience is also that we dont know which values were actually set by the user.
This will be handy in a future if we try to implement a simpler filter interface, where only the fields that are chosen by the user are showed on screen.

Also, with current system, we don't know if a field with a defaulted value (eg: "any") was actually a value set explicitly by the user
This may be relevant in hypothetical scenarios:

• when the default value for filter properties may change over time or per user/project.
• when trying to combine two filter properties sets
  This may come from the implementation where a user may have a custom default filter, and loading another stored filter means overlaying that one over the default.

So, the proposed feature serves as a clean up, but prepares the ground for future improvements.

Note that in current filter treatment, and more refined in PR 862, filters don't need to have all the properties defined. The only implementation needed is not store garbage, and keep track of actual set values.

Regarding the concept of default filter:
At present, we consider a default filter is one where all fields are "any" (or equivalent), with the exception of "hide_status", wich by default is set to "closed".
If the user, over this default filter, sets and additional field "priority=xxx".
Should we store this filter as:
[priority=xxx,hide_status=closed]
or only as:
[priority=xxx]
?