Detect if defradb is being run in test mode

[islamaliev]

We currently employ a method for detecting test mode execution that may not be optimal or align with conventional practices:

func init() {
    arg := os.Args[0]
    // If the binary is a test binary, use a deterministic nonce.
    if strings.HasSuffix(arg, ".test") || strings.Contains(arg, "/defradb/tests/") {
        generateNonceFunc = generateTestNonce
        generateEncryptionKeyFunc = generateTestEncryptionKey
    }
}

The condition strings.Contains(arg, "/defradb/tests/") is specifically included to accommodate debug mode execution.

While we have explored using build tags (//go:build test) for conditional compilation, which would be the ideal solution, we encountered limitations. The build tag only takes effect when explicitly passed (-tags=test). We expected Go to automatically set a test-specific build tag during test runs, but it doesn't seem to be the case. Manually passing this flag is not a viable option as it would impede our ability to execute tests seamlessly from IDEs.

We need to implement a more robust and conventional method for test mode detection that:

• Doesn't rely on string parsing of binary names or file paths
• Works consistently across different execution environments (standard test runs, debug mode, IDE integrations)
• Aligns with Go best practices for test configuration

[AndrewSisley]

Note, it is possible to remove the hard coding of nonce and crypto keys (and thus removing the need for the test code in the description), this has been done in 2801-rm-hardcoded-test-cryto but has not been cleaned up. This allows us to test production behaviour instead of test behaviour, although it does bring a complication to commit query testing, as the cids are not deterministic, and the order of results is driven by their values, meaning I had to introduce support for order-agnostic assertion.

[islamaliev]

@AndrewSisley the branch is on your fork. I leave a link here so it's easier to find https://github.com/AndrewSisley/defradb/tree/2801-rm-hardcoded-test-cryto

I will wait for the PR to leave comments.

I also thought about a similar approach, but in the future we want to let users choose which encryption algorithm they want to use (not only AES). Didn't put too much though into how we want to assert that a specific algorithm was used. Maybe we could solve it on unit test level instead of integration tests.