Allow event_filter to be set via GET/POST in addition to cookie

What does this MR do?

Are there points in the code the reviewer needs to double check?

Why was this MR needed?

Screenshots (if relevant)

Does this MR meet the acceptance criteria?

• Changelog entry added, if necessary
• Documentation created/updated
• API support added
• Tests
  • Added for this feature/bug
  • All builds are passing
• Review
  • Has been reviewed by UX
  • Has been reviewed by Frontend
  • Has been reviewed by Backend
  • Has been reviewed by Database
• Conform by the merge request performance guides
• Conform by the style guides
• Branch has no merge conflicts with master (if it does - rebase it please)
• Squashed related commits together

What are the relevant issue numbers?

#1801 (moved)

added Community Contribution label

@igas Thanks!

I think we should address Adam's points from https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/5699:

1. I think that we should only accept a single filter.
2. I think that we should also pass these parameters when generating URLs to the RSS feeds. If we don't do that, basically nobody will discover this option.

@igas Are you still interested in finishing this one?

assigned to @igas

Hi @rymai, yes, sorry for late response. I think first was discussed in original MR and it's kept for backward compatibility (according to comment in code). Should I refactor EventFilter?

it's kept for backward compatibility

@igas The backward compatibility is for the cookie strategy only as a cookie can outlive several versions of GitLab, so if we have "filter1,filter2" in the event_filter cookie, we correctly extract and use the first filter only (e.g. filter1 in this case).

The current way of filtering allows only one filter to be used so, for this new feature of being able to pass a filter in the URL, we should only handle this case and assume only one filter is given, e.g. ?event_filter=filter1&foo=bar.

We should also add this filter (if present) in the RSS feeds URLs.