Pass logging context to Detector.FromData

[rgmz]

Description:

This PR touches a lot of files, however, the sole change is replacing import ... "context" with import ... "github.com/trufflesecurity/trufflehog/v3/pkg/context".

Why?
While the logging context is not used in any detectors (as far as I'm aware), it is incredibly useful for local debugging, similar to #2191. Right now it is difficult to figure out what specific chunk triggered a detector, and in many instances logging is just done with fmt.Printf which is devoid of any context. Perhaps there is an easier or better way to accomplish this — let me know.

An alternative is to change Detector.FromData to Detector.FromChunk (#1517). However, that's a larger change that could be accomplished via less invasive means (#1741).

Checklist:

• Tests passing (make test-community)?
• Lint passing (make lint this requires golangci-lint)?

[mcastorina]

First off, thanks for taking the time and effort for this change.

Perhaps there is an easier or better way to accomplish this — let me know.

Would using logContext.AddLogger accomplish what you're doing?

trufflehog/pkg/context/context.go

Lines 162 to 170 in b0fab16

	// AddLogger converts a context.Context into a Context. If the underlying type
	// is already a Context, that will be returned, otherwise a default logger will
	// be added.
	func AddLogger(parent context.Context) Context {
	if loggerCtx, ok := parent.(Context); ok {
	return loggerCtx
	}
	return WithLogger(parent, defaultLogger)
	}

In the detector you could do something like the below when needed for debugging. Since we already pass a log context into the detectors, it should preserve the key/value pairs.

logger := logContext.AddLogger(ctx).Logger()

[rgmz]

That's bizarre: I swear that didn't work before but it does now. Perhaps I accidentally mixed in a call to context instead of the github.com/trufflesecurity/.../context which doesn't preserve values (Slack thread). 😵

[mcastorina]

Gah, sorry I missed that thread! Yeah, I think the log info would get lost if it's wrapped in a stdlib context. I wonder if there's a way to traverse the ancestry of contexts instead of only looking at the child..