Brainstorming "API" for tables used in containers

Right now the current "API" for using a table in a container (see #6209) is to apply pid_with_namespace to the predicate.

I find the column name is slightly confusing to folks not using osquery for containers. I want to brainstorm some alternatives. Please keep in mind that I have not tested the applicability of the following, it is very possible that some ideas do not work in practice.

1. Introduce a function that resolves pid to namespace and only include mount_namespace_id as an added column. I am imagining a SELECT * from os_version WHERE mount_namespace_id = pidToNamespace(12345);.

2. Introduce a VIEW for each of these tables such that you have a SELECT *, pid_with_namespace, mount_namespace_id from os_version, call this containerized_os_version and make the two new columns HIDDEN. This means normal calls to os_version remain the same.

3. Make use of the "column is used" functionality within virtual table implementations to populate context with information. Then you can have SELECT *, pidToNamespace(12345) from os_version, and the columns can become HIDDEN (see 2).

4. Implement some SQL meta-programming to create an experience like SELECT * FROM @containerized(os_version, pid=12345); or SELECT * FROM @containerized(os_version, namespace=12345);. We then intercept raw-queries and parse out the @containerized<$> to rewrite the query (yikes). Essentially create a temporary VIEW for this table and select from that.

5. Set pid_from_namespace to HIDDEN and keep mount_namespace_id as not HIDDEN. I do not think pid_from_namespace provides a lot of value as a returned column. The namespace ID should be enough to differentiate between containers. I would hope that the container-related tables return this namespace ID somehow?

Start by reading issue #6209 and reviewing the current pid_with_namespace approach described here. Compare the five proposed API designs against the existing container-table behavior and determine which direction is viable. The issue identifies no implementation files or tests; done would require an agreed design before implementation can be scoped.