Refactor defer-close with error handling

[facuMH]

This PR contributes to https://github.com/Fantom-foundation/sonic-admin/issues/90

This PR adds real life use cases of both functions provided the caution package to properly handler errors in case of defer and close.

This PR fixes some of the unhandled errors reported by the external audit. Most (if not all) of them are from either defer close patterns or similar cleanups or unhandled close errors.

Test list to verify we don't have double closes (or other errors) and panic now because error is no longer ignored:

• run make test
• Norma test
  • demonet/static.yml
  • demonet/dynamic.yml
• testing suggestions ?

[LuisPH3]

I saw some details that need handing;

Additionally, I would like to avoid using caution.CloseAndReportError for scenarios without defer, it does nonstandard error handling, and it may be a little convoluted to read. We can talk about a replacement.

[HerbertJordan]

I do not really like that most of this refactoring is introducing named return values for non-trivial functions. It makes functions harder to read, and without an IDE highlighting it is difficult to verify that a return value name is not shadowed in a nested scope.

But I do understand that this seems to be a requirement imposed by the caution package, and alternatives might be even more cumbersome.

However, I would like to ask to reconsider the naming and placement of the function IfErrorAddContext as addressed in the comments. Please have a look.

[LuisPH3]

this case is not defered, close can be called using normal procedures.

[LuisPH3]

since the first time i saw this line, i dont really know what to do with it.
The search algorithm will look for something not returning an error and producing errors may be the intended use.

The context we add to warn is not good.

• Write a complete sentence in warn: "error produced during parallel search"
• Add a comment explaining the issue, so that the problem is understood in case this line turns too verbose (which could affect performance of some hot region)

@HerbertJordan @kjezek do you know what this code is about?

[HerbertJordan]

This code is the implementation of the log-filter feature. You can send RPC queries to the service asking for log messages listing a given set of topics. This function is searching for those and does a call-back on onMatched for each element and, as it looks like, a final one passing a nil to indicate that all matches have been reported and that there are no more.

The only time this function is actually used is in line 94 above, where onMatched returns an error if, for instance, the execution context is canceled. Another option is that the consumer of the match failed to consume it, which seems to be ignored, as shown in line 116.

I guess the best option here, matching the action in line 116, is to simply ignore the error.

[LuisPH3]

//	}
func ExecuteAndReportError(err *error, f func() error, message string) {
	fErr := f()
	if fErr != nil {
		*err = errors.Join(*err, fmt.Errorf("%s: %w", message, fErr))
	}
}

this if is superfluous.

[HerbertJordan]

This code is the implementation of the log-filter feature. You can send RPC queries to the service asking for log messages listing a given set of topics. This function is searching for those and does a call-back on onMatched for each element and, as it looks like, a final one passing a nil to indicate that all matches have been reported and that there are no more.

The only time this function is actually used is in line 94 above, where onMatched returns an error if, for instance, the execution context is canceled. Another option is that the consumer of the match failed to consume it, which seems to be ignored, as shown in line 116.

I guess the best option here, matching the action in line 116, is to simply ignore the error.

[LuisPH3]

Please, Add one deferred error missing : gossip/handler.go:700:19: defer msg.Discard()

[facuMH]

moved to 0xsoniclabs/sonic#7