Update front-end to allow for full time period searches

[noahmanger]

So that users can search for receipts and disbursements across all time, update the front-end filters to not restrict to a two-year period.

---

This is dependent on the API work happening but we can work on figuring out what we want this to do.

Update filter logic

This is the trickiest part, since we want to start by first expanding to 6 years to make sure we're ok performance-wise. Presumably we could get this to work using the current filter validation logic, but by changing from a 2 year range to a 6 year range. It raises some questions:

• Should users select any even year (2016, 2018, 2020, etc.) and then the period becomes the six years preceding that year? I think this makes the most sense, because that way you could have an given full senate cycle.
• Do we show the date picker?
• Do we need to pass something like six_year_transaction_period or is it enough to just enforce the time constraint client-side?

I got a start experimenting with this in #2213 and 18F/fec-style#747.

Update links to receipts & disbursements pages

• Remove two-year period filter and validation logic
• Consider whether or not we want a default time period of some length, even if it can be removed
• Go through and update all links to these pages that include the transaction period parameter
• When on a candidate profile and looking at a 4 or 6 year period, the links should go to the full 4 or 6 years by using min_date and max_date
• Update all links on election pages
• Ensure proper formatting of all date params

I got a start with this in #2202 , though that PR goes a little far in completely removing the time period restriction all together.

Update candidate pages

• Update candidate page to query 4 and 6 years of transactions
• Candidate page totals need to be adjusted to allow 4 or 6 year totals, but this requires API work. Is it ok to keep these restricted to two year ranges? If so, make sure that coverage dates make sense. Or maybe they should be hidden if looking at a full election range?

[noahmanger]

The trickiest part about this is figuring out the right interaction for a six-year range. Unlike with two years where it makes sense to ask somebody to select a two year period and then adjust dates within it, 6 year ranges are more difficult. Here's a couple attempts, with their challenges.

Option 1: Complex, adaptation of what we have now

One direction would be to take the current component but have the cycle select count for 6 years and have all the date selection and validation and everything work the same way.

But because we want to support within 6 years of any max date, we'll necessarily have overlapping ranges (ex. 2009-2014, 2011-2016, 2013-2018) which would make for a confusing menu of options. And just showing the end year (e.g. 2014, 2016, 2018), it's tough to communicate that the range actually includes the 6 years prior.

Also, 6 years of months is obviously a lot to pack in.

Option 2: Simple validation

On the other hand, we could go simpler and just have beginning and ending date fields, and set up validation and some instructions to show how you must select dates within 6 months of each other.

---

And of course, there's always the option to go back to the drawing board. In the interest of getting something out there sooner than later, I wanted to see if we could make a simple solution work first, so if anyone sees a way to make either of these options work, then please share.

cc @jenniferthibault @LindsayYoung

[LindsayYoung]

I like our date picker, but looking at six years I think I would prefer the simple validation. And if someone thinks of a better idea we can always swap it out later.

[jenniferthibault]

For a fast solution, I'm also on board for Option 2 with simple validation.

If we want to revisit this, I'd be interested in an adaptation of this example from SAP which uses a calendar picker for month and year

[noahmanger]

Cool. Thanks for the feedback! I think I'll need help communicating the time restriction, but that's definitely the easier implementation.