Set future/pending transactions to uncleared

[dequis]

This adds support for sending 'uncleared' in the cleared field that goes
to YNAB if the dumper passes a falsy value in that field.

For the default dumper, this checks if the transaction date is in the
future.

For the N26 dumper, this reuses the pending transaction checks, so if
skip_pending_transactions is disabled those pending transactions are
sent to YNAB, to be hopefully picked up by the transaction matching.

---

This works, but I don't know if the transaction matching will be good enough in practice. So I'll be running this for a couple of weeks to see how it goes.

I have no way to test the non-N26 dumpers, and test coverage of those seems weak.

[gitviola]

This is amazing @dequis! Thank you very much for your PRs. I just merged the other ones.

Let me know how it works for you. I use two other banks, so once you say it works for you, I could clone your fork and try it on my end. If it all goes well we can merge it. The code looks excellent to me!

[gitviola]

Maybe here we could use Date.current because the date method will return a date object (limitation of some dumpers, most banks don't return a timestamp..) and I think it reads a bit better to see a date comparing with a date. WDYT?

[gitviola]

Good catch! Thank you

[dequis]

Welp, the ynab-side matching isn't doing its thing.

Some of them are wildly different yeah, but the flixbus one is the same except (i guess) the exact timestamp.

This does have the advantage of leaving duplicate transactions as uncleared, so it's easy to tell which to keep.

Aaaaand after writing this I just noticed this one in the docs:

If import_id is omitted or specified as null, the transaction will be treated as a “user-entered” transaction. As such, it will be eligible to be matched against transactions later being imported (via DI, FBI, or API).

Which.. sounds easy enough, but will probably just get me uncleared ones several times.