Add `config-list` command to the CLI

[chelma]

Description

As a part of https://github.com/arkime/aws-aio/issues/87, this task is to add a way to list the code/config bundles that have been deployed to the Capture and Viewer nodes.

Acceptance Criteria

• Users have a way to visualize which bundles have been deployed so that they can retrieve and/or re-deploy specific bundles with future commands

[chelma]

Some initial thoughts as I think through the user experience here. There's a lot of ways to structure this so I'll start with making a list of actions that a user might want to perform.

• Find the full details of a config bundle based on its config version or MD5 hash. Could be useful to find the config version of a bundle you have on disk, or confirm the installed bundle is the version you expect.
• List details of config bundles from a specific time range. Useful to find what version of the config was deployed at a specific timeframe (e.g. during an incident).
• List the details of the most recent bundles (up to N in total, with N being user supplied). Useful to just browse the config bundles and could be used to replicate the other options with a large enough N and some client-side filtering.

Additionally, we'll want a way to specify whether we're looking for/listing Capture config or Viewer config.

[chelma]

Whoops, didn't mean to close the ticket

[chelma]

Some additional thoughts:

• The details we want about our config bundles are currently stored in custom, user-specific S3 object metadata.
• There doesn't appear to be a way to list the user-specific S3 object metadata for multiple objects; the two ways appear to be GetObject (which downloads the object) or HeadObject (which just retrieves metadata for an object). This means that if our primary store of this metadata for config bundles is in S3, we'll need to retrieve the metadata for each object each time we need it. Right now, we only store the current and previous (if it exists) config bundle metadata in Param Store in order to save keys, which I think is the right call. In the future, we'll want to move from Param Store to a "real" DB and have an open issue for it; I've updated it to mention this consideration (https://github.com/arkime/aws-aio/issues/74).
• We could cache the config metadata locally when we retrieve it. It may also be we have other information like this we want to cache locally as well. However, I don't think that's a strict requirement for this task and think it solves a problem better solved with switching to something like DDB.
• Since we don't have a good way to pull multiple S3 objects' metadata at a single time, we appear to be stuck pulling all our objects' metadata and either returning it or filtering once we've pulled them, so implementation for all the use-cases mentioned above is basically the same except for retrieving a specific config bundle by version number, since that's embedded in the S3 key. There are some cheeky things we can do like use the object upload time for time filtering instead of the bundle creation time (which are slightly different), but still.

[chelma]

After some thought, I think I'll start with the following experience:

• Create a single list command for both the Capture and Viewer config, with a flag to indicate which to retrieve - config-list --capture and config-list --viewer. This maintains congruence with our existing config-update command, which itself can be expanded to use the same nomenclature to update JUST the capture or viewer config at a later date.
• In this case, however, the --capture/--viewer flag is a required argument. This could be an indication that we should instead split this into two separate commands (config-capture-list and config-viewer-list), but I think there's enough benefit in matching the nomenclature of our update command to accept a bit of wonk in this choice.
• The default behavior will be to return the details of ALL capture or viewer config bundles. We can add a parameter to limit responses to a specific count later.
• The user can filter the returned config bundle info with --before and --after parameters (or the combination) which will only return bundles from a specific timeframe.
• The user can get just the current and previous bundle's info with the --deployed flag, which can pull it from Param Store.

It should be easy to add the other use-cases (filter by MD5, filter by config version, limit responses to specific count) later in case those end up being in high demand. Will create a follow-up ticket to capture them for later consideration.

[chelma]

After playing around with things a bit more, I suspect most people would be satisfied with just the following:

• The default behavior is to return all configs
• The --deployed flag returns the current/previous config info

Going to move filtering by --before and --after to the list of follow-up features.

[chelma]

Another side-note - calling HeadObject on each config bundle is pretty slow; it takes ~3 seconds to handle 6 config versions. We'll want to take another pass on this, per previous discussion (see https://github.com/arkime/aws-aio/issues/139#issuecomment-1850038929).

[chelma]

Acceptance criteria met; code merged. Resolving.