Implement IRR-based filter generation

[forkwhilefork]

One option is to use an external binary like bgpq4, but my preference is to query my instance of IRRd4 directly. (Edit: this is possible with the -h option.) I'd prefer to use the GraphQL interface that just got added - may have to update to the latest (non-release) version to get that functionality though.

[forkwhilefork]

Will need to add a CLI argument for the API endpoint (e.g. https://irr.forksystems.net/) and some internal functions to handle the different queries needed. I should also look into GraphQL client libraries.

[forkwhilefork]

Okay, I think there are two parts to this:

1. When you set the filter method to IRR for a peer, it "include"s a separate file where the prefix-list is defined.
2. We need a tool that pulls data from IRR and outputs a bird-formatted prefix-list. As far as I know, there is no tool that uses the GraphQL API introduced by IRRd4. However, bgpq4 (using whois) would work perfectly well for this.

We just need to add a cron job that updates the prefix-list file referred to above (where the command to run is something like bgpq4 -h irr.forksystems.net -b -4 as-example -A -l bgp_customer_example_v4 > /path/to/file.conf, and then the analogue for v6). Then, some additional items arise:

1. What is the UX for this? Can we programmatically (and idempotently) add a cron job for a peer file generation? If not, the user has to add it manually. We'd want to print out the command so the user can just copy/paste, but we'd likely have to print it every time the config is generated...
2. We need to add a global item in the config for the IRRd server hostname.
3. It may be worth adding a global config item and/or per-peer config items for the allowed IRR DB sources.
4. We need a global and/or per-peer config item for filter regeneration interval.

[forkwhilefork]

Ah - we should make a file in /etc/cron.d/ (e.g. bird_irr) and overwrite that file on each run.

See here: https://stackoverflow.com/a/610860

[forkwhilefork]

Adding another file we need to keep track of adds more complexity than I expected. Depending on our operating mode, we usually need to compare the current and proposed versions of a file, and act differently if they are the same or not. But now we have to do that process for at least two files (the config monolith and the cron file) and combine the results somehow. I think the file comparison logic needs to be refactored and maybe moved into a separate function.

[forkwhilefork]

I split out the config-diff thing into its own issue. This one is now blocked by #43.

[forkwhilefork]

no longer blocked