[Framework] Improve saferTrie node's value

[weilerN]

Motivation

Described in the Jira - https://iguazio.atlassian.net/browse/NUC-486

Root Cause

Memory Layout:

[]string:        24 bytes (slice header) + 32 bytes (heap allocation for 2 strings) = 56 bytes total
CanaryTarget:    32 bytes (stack allocated, no heap allocation)

Performance Improvements:

• Creation: Faster, avoids heap allocation
• Access: Faster, no pointer dereferencing
• Memory: ~43% reduction in memory footprint
• Garbage Collection: Lower GC pressure
• CPU Cache: Improved locality and access speed

Description

This PR introduces a memory-optimized approach for storing values in the safeTrie.
Instead of using []string to represent function names, this change replaces it with a lightweight struct-based abstraction: FunctionTarget.
It includes two concrete implementations:

• SingleFunctionTarget – holds a single function name
• CanaryFunctionTarget – holds exactly two function names

The FunctionTarget is propagated to the upper cache layer, and the related interfaces were renamed for clarity and consistency.

Affected Areas

Since the only usage of the FunctionTarget resides inside the cache, there are no affected areas.

Testing

• Added unit tests for SingleFunctionTarget and CanaryFunctionTarget
• Updated all relevant cache unit tests to align with the new structure

Changes Made

• Introduced the FunctionTarget interface with SingleFunctionTarget and CanaryFunctionTarget implementations
• Refactored safeTrie and cache layers to support and propagate the new interface
• Aligned interface method declarations for readability and consistency with the FunctionTarget design

Additional Notes

• Expanding the use of the FunctionTarget abstraction outside the cache (e.g., surfacing it in the cache interface) is left open for further discussion in the code review.

[TomerShor]

I'm not convinced that the memory improvement is this critical that this change is required.

But regardless, since you anyway use a slice string in CanaryTarget, isn't it better to only have a single, static struct?
something like:

type FunctionTarget struct {
    mainFunction string
    canaryFunction string
}

Then, you don't need the interface at all.
You can even define the as string pointers and might save even more memory.

[rokatyy]

Very nice! I'm actually on the side of using interface, I think it provides more flexibility and allows to hide all logic under the hood. Just one comment, other than that lgtm

[rokatyy]

not needed anymore, part of Add anyway

[weilerN]

Done here- CR comment- rephrase comments

[weilerN]

I'm not convinced that the memory improvement is this critical that this change is required.

But regardless, since you anyway use a slice string in CanaryTarget, isn't it better to only have a single, static struct? something like:

type FunctionTarget struct {
    mainFunction string
    canaryFunction string
}

Then, you don't need the interface at all. You can even define the as string pointers and might save even more memory.

Thanks for the feedback, @TomerShor
While the memory gain alone may not justify the change, this PR brings two additional benefits:

1. Maintainability and Flexibility – The interface allows each function type (single or canary) to define its own logic. This avoids sprinkling conditionals throughout the code and makes it easier to read and add new types or behaviors in the future.
2. Encapsulation – Using separate structs (SingleFunctionTarget, CanaryFunctionTarget) avoids introducing implicit semantics like priority (e.g., mainFunction, canaryFunction).
   The FunctionTarget abstraction keeps the logic self-contained and aligned with the actual use cases.

I hope this explanation clarifies my approach — I believe these changes are beneficial, and I’d appreciate your consideration in proceeding with the proposed changes.

[TomerShor]

Looks good and approved, but with an open question

[TomerShor]

This can also be a wrapper for a string

Suggested change

	type SingleTarget struct {
	functionName string
	}
	type SingleTarget string

If we're talking about optimization, what is the difference between the two?

[weilerN]

Agreed, fixed here - CR comment-change singleTarget from struct to a string wrapper