Agentk: Fix error type and reporting of error resulting from direct k8s actions in RD module

Description

Currently, errors encountered when directly invoking k8s actions are classified as applier errors which is incorrect. These should perhaps come under a separate category and reported accordingly to Rails.

Proposed Solution

Changes in Agentk

• Create a dedicated error type: kubernetes for the above cases
• Since there are now multiple error types, modify the errorTracker to capture this information

type errorTracker struct {
	mx    sync.Mutex
	store map[errorTrackerKey]operationState
	wg    wait.Group
}

type errorTrackerKey struct {
	name      string
	namespace string
}

// operationState indicates the state of an async operation as it is being watched by the errorTracker.
type operationState struct {
	// version indicates the version of the operation for which the state is being tracked
	version uint64

-	// err contains the error available at the end of an async operation
-	err error
+	errDetail errorDetail
}

+ type errorDetail {
+ 	errorType ErrorType
+ 	err 	  error
+ }

• The applierErrorTracker in reconciler will be updated to be a general purpose error tracker that just doesn't track applier errors as having dedicated error trackers for each new error type will only add to the complexity of reconciler

Changes in Rails

• Add support for the error type in the validation logic

Deployment steps

• Deploy changes in Rails first
• Deploy changes in Agent

Technical Requirements

• Agentk: Support new error type and report it to rails
• Agentk: Add specs to verify changes introduced
• Rails: Support new error type reported from agentk
• Rails: Add specs to verify changes introduced

Acceptance Criteria

• Agent is able to report the errors with the new error type
• Rails is able to accept errors with the new error type

Design Requirements

• NA

Impact Assessment

• Error types for some errors may change after a deployment but since these are only logged and dont have any logic that uses them in rails, there should not be any backward compatibility issues

Availability and Testing

Ensure updated test coverage in unit/integration/feature tests.