Port influx_inspect tools to influxd inspect subcommand

[stuartcarnie]

What

Users will require access to the existing influx_inspect tools, available in 1.x. The 2.x tools were disabled / removed as they are not compatible after the 1.x migration.

This epic captures the list of influx_inspect commands to be ported to influxd inspect

[stuartcarnie]

This represents more than a single sprint (two weeks) worth of work, hence earning the 9,000 estimate.

The tools are not a drop-in from 1.x and 2.x as they have to interact with 2.x metadata.

I would expect this be converted to an epic and individual issues created for each tool. Some may be easier to port than others, depending on their requirements.

[danxmoran]

@stuartcarnie I notice that the 1.x export subcommand isn't included in the list here. Was that intentional, or an oversight?

[stuartcarnie]

@danatinflux influx export is already available in 2.0, but is limited to exporting resources. Tagging @timhallinflux and @russorat to elicit their feedback / ideas.

[timhallinflux]

We need to export the contents of a bucket into LP.

[rbetts]

@danxmoran (deleted my previous comment - which wasn't particularly helpful.). But let's chat about this if you have any questions? In general, the goal of the influxd inspect commands are to allow offline data processing. We use this for a few of scenarios: where we want to compute offline w/o putting load on the DB; where we want to get information from TSM but the DB can't run for some reason; where we want to add a rarely-used feature and the complexity of adding it to the running DB is too high but the complexity/cost of doing it offline is acceptable.

Some of the influxd inspect commands (specifically export) do overlap with API-based capabilities. That's okay - there are reasons to want them both online and offline.