Spring cleaning - removing dead code and other source tree care

[anderbubble]

Description of the Pull Request (PR):

Holistic update and cleanup for the source tree. Mostly removing dead code using the deadcode utility from https://go.dev/blog/deadcode.

deadcode -test ./...

Also updated LICENSE_DEPENDENCIES.md and moved a few minor files around.

Before submitting a PR, make sure you have done the following:

• Signed off on all commits (e.g., using git commit --signoff) in agreement to the DCO
• Read the documentation for contributing to Warewulf
• Added changes to the CHANGELOG if necessary
• Updated userdocs if necessary
• Based this PR against the appropriate branch (typically main)
• Added myself as a contributor to the Contributors File

[anderbubble]

@mslacken this is something I've been thinking about for a while, but I hadn't found a good tool to do it with. Tonight I found deadcode, which seems to do what I've been looking for.

There's a fair bit removed here, so I understand if it sparks some concern. Some of the removed code is reasonably expected, just unused; for now, I took the tact that if it's not tested then it's more risk than benefit. But if code was in the testsuite then I considered it used, even if it's not used anywhere else.

I see there's some linter failures, so I'll address those.

Let me know what you think.

[mslacken]

Prince Arthas might not be happy with this.
Besides from that, having less coffee is always better and a great idea.
Can we postpone this after we have:

• 4.5.1
• Merged in the dracut code
• Removed NodeInfo
  Especially having removed NodeInfo will create a lot more of dead code.

I also would like to ask you if there is a tool with which we can reduce vendor depencies?

[anderbubble]

Definitely fine for this to wait until after v4.5.1.

For NodeInfo, I'd say let's go ahead and merge this in, and then just do it again after the NodeInfo refactor.

I got the errors cleared.

[anderbubble]

For NodeInfo, I'd say let's go ahead and merge this in, and then just do it again after the NodeInfo refactor.

Eh, I'm probably wrong. This can wait until after NodeInfo. This was really easy to do, and I could see it being really disruptive to the NodeInfo refactor.