Add `ps --filter` (and maybe `--last <N>`) features

[emk]

docker ps has some options for filtering the containers it returns:

Usage:  docker ps [OPTIONS]

List containers

Options:
  -a, --all             Show all containers (default shows just running)
  -f, --filter value    Filter output based on conditions provided (default [])
      --format string   Pretty-print containers using a Go template
      --help            Print usage
  -n, --last int        Show n last created containers (includes all states) (default -1)
  -l, --latest          Show the latest created container (includes all states)
      --no-trunc        Don't truncate output
  -q, --quiet           Only display numeric IDs
  -s, --size            Display total file sizes

If any of these correspond to flags in the underlying protocol, we may want to implement them. See also #4.

[erithmetic]

At this point I fear we start venturing into the realm of basically reinventing docker-compose (what's next, parsing email? 😉 ). This is how docker-compose implements its ps command - by using filters

[emk]

At this point I fear we start venturing into the realm of basically reinventing docker-compose

docker-compose seems to be in a weird maintenance status right now:

1. (Important for everything else: It's written in Python, not Go like all the other Docker tools.)
2. A big chunk of what it does is being moved into Docker Application Bundles.
3. Most of its features have been ported from Python to Go by libcompose.
4. The main docker-compose itself is being kept up to date with new Docker features like networks and named volumes, but other than that, many useful developer-oriented feature requests remain open on GitHub for many months at a time.

It would certain be possible to access ps information by shelling out to docker or docker-compose and parsing the JSON. But eventually you would wind up with a largish library of command-invocation and JSON-parsing code that interfaced with those tools.

I decided that it was easier to just talk to the daemon directly, since there was already a reasonably complete library for doing so that I could get running again in a day.

As for cage features, the ability to inspect containers using boondock is what powers both the new cage status enhancements and allows cage up ---init to figure out the network addresses and exposed ports of various containers. There's a lot more cool stuff we can do, and not all of it is exposed by the CLI (and even if it were, we'd have to write and maintain a library to call the CLI).

[erithmetic]

I guess what I'm saying is, is a global ps important enough to start digging into raw docker land, or can we get by with per-pod ps that just outputs docker-compose -f .cage/pods/pod.yml ps ?

[emk]

This issue is on the boondock repo, not the cage repo—we're not implementing a literal ps CLI, we're updating a pre-existing Rust library which has high-level data types corresponding to the JSON emitted by ps, inspect, etc. The alternative was writing a full-fledged Rust library that asks the docker CLI for this data and parses it.

This bug is for tracking breakage with that library's Rust equivalent of ps.