refactor: docker inspection refactor

[miki725]

• [x] Followed the steps in the contributor's guide: https://crashoverride.com/docs/other/contributing#filing-the-pull-request
• [x] PR title uses semantic commit messages
• [x] Filled out the template to a useful degree
• [x] Updated CHANGELOG.md if necessary

Issue

This is prep work for adding provenance support

https://github.com/crashappsec/chalk/issues/180

Description

Provenance will require inspecting image from the registry manifest. This PR split out docker functionality into various independent pieces among which is the manifest handling refactor. We now parse the manifest json and return appropriate nim data-structures for easy handling of the manifest lists/images/configs/layers. This will allow us to easily interact with the registry to collect metadata from the registry, same as we do for local docker image inspect ....

In addition all the inspection logic was in multiple files across docker_base/codecDocker, etc which was very hard to follow so all of the inspection logic was moved to independent files under docker/. important files:

• inspect - runs docker inspect command
• manifest - fetches manifests/config info from registry
• collect - map docker metadata to chalk object
• scan - find new chalk objects to collect info for

Testing

make tests args="test_docker.py --logs"

Next Steps

Next PR all the build logic can be redone to support provinance which will remove all the magic docker build command flag handling.

[ee7]

And nit for merging: our PR template has:

• [X] PR title uses semantic commit messages

and that specifies:

The refactor type is used to identify development changes related to modifying the codebase, which neither adds a feature nor fixes a bug - such as removing redundant code, simplifying the code, renaming variables, etc.

where the types of changes are categorized as:

• Development - sort of maintenance types which classify changes, intended the developers, that don’t actually affect the production code but rather the development environment and workflow internally
• Production - sort of enhancement types which classify changes, intended the end users, that solely affect the production code

but this PR does technically make user-facing changes (fixing a bug, and adding/removing keys). I don't know what our convention for commit message prefixes, but we might want to either:

• Use feat or fix as the commit prefix when merging, if you're squashing
• Merge with a merge commit, with commits with different prefixes, if they're individually correct. (I personally don't like what GitHub calls "Rebase and merge", since without special attention in advance it's difficult to immediately see from the terminal which PR the commits on main are associated with - I know GitHub exposes it in the web UI).
• Link a different convention, if we want to allow commits of kind refactor to make user-facing changes
• Or e.g. change the PR title, and use refactor for the squashed commit prefix, and specify that only PR titles follow the given convention (that seems weird though)

Whatever. Just to point it out, in case the merged commit prefix is supposed to have some significance.