feat(controllers): Enable multiple controllers with different label selectors for the same entity type

[stevefan1999-personal]

Overview

This PR introduces support for registering multiple controllers for the same Kubernetes entity type, each with different label selectors. This enhancement allows operators to handle different subsets of resources using specialized controllers based on label-based filtering.

Fixes #909

Key Changes

🔧 Core Interface Updates

• Modified IEntityLabelSelector<TEntity> to IEntityLabelSelector<TEntity, TSelf> to enable type-safe registration of multiple selectors
• Updated IOperatorBuilder.AddController<TImplementation, TEntity, TLabelSelector>() method signature to match the new interface constraint

🏗️ Service Registration Improvements

• Enhanced OperatorBuilder to properly register multiple label selectors as distinct services
• Simplified controller registration by making the parameterless AddController<TImplementation, TEntity>() method delegate to the selector-aware version with DefaultEntityLabelSelector<TEntity>
• Removed problematic open generic registration that prevented multiple selector registrations

🔍 Resource Watcher Enhancements

• Refactored ResourceWatcher<TEntity> to ResourceWatcher<TEntity, TSelector> for selector-specific watching
• Updated LeaderAwareResourceWatcher<TEntity> with the same pattern for leader election scenarios
• Maintained backward compatibility by providing single-generic overloads that delegate to the new implementations

✅ Comprehensive Test Coverage

• Added test cases in OperatorBuilder.Test.cs to verify multiple selector registration
• Created TestLabelSelector2 to demonstrate multiple selector scenarios
• Updated existing tests to reflect the new service registration patterns

Benefits

1. Multi-tenant Support: Different controllers can handle resources based on tenant-specific labels
2. Environment Separation: Separate controllers for dev/staging/prod resources within the same cluster
3. Feature Flagging: Controllers can target resources with specific feature flags
4. Performance Optimization: Specialized controllers can focus on specific resource subsets

Backward Compatibility

✅ Fully backward compatible - existing code using single controllers continues to work without changes. The parameterless AddController<TImplementation, TEntity>() method automatically uses the default label selector.

Example Usage

// Register multiple controllers for the same entity type
builder.AddController<ProdController, MyEntity, ProdLabelSelector>();
builder.AddController<DevController, MyEntity, DevLabelSelector>();

This enhancement significantly improves the flexibility of the KubeOps operator framework while maintaining full backward compatibility with existing implementations.

[buehler]

I like the idea :)
If it is backwards compatible, then even more.
Please also update the documentation according to the changes.

[stevefan1999-personal]

I like the idea :)
If it is backwards compatible, then even more.
Please also update the documentation according to the changes.

Just a little poke, anything missing?

[buehler]

Hey @stevefan1999-personal

I reviewed parts of the code and I have some thoughts / questions:

• There are conflicts in the files which must be resolved
• There are issues with linting which will block merging anyway
• Instead of using the simpler as generalization to the more specific, could it be the other way around? Such that you do not need to change a whole lot of implementation detail
• Could it be beneficial to just use a property in the interface of IEntityController that returns a list of labels to filter (with a default implmementation of none) and then in the logic that selects the controller fetch a list of registered objects from the DI container instead of having specialized interfaces? It looks like an awful lot of typechanges.

So in my head, I'd like to use something like:

interface IEntityController<T> {
ILabelSelector? LabelFilter {get;} = null;
// rest...
}

// ResourceWatcher{TEntity}.cs
 private async Task ReconcileDeletionAsync(TEntity entity, CancellationToken cancellationToken)
    {
        requeue.Remove(entity);
        await _entityCache.RemoveAsync(entity.Uid(), token: cancellationToken);

        await using var scope = provider.CreateAsyncScope();
// CHANGE HERE: use a list of entity controllers and then select the one that fits best.
// same change goes for the reconcile Modification func
        var controller = scope.ServiceProvider.GetRequiredService<IEntityController<TEntity>>();
        await controller.DeletedAsync(entity, cancellationToken);
    }

What do you think about this?

As far as I see, this would preserve the default behavior for everybody without a breaking change and allow you to overwrite the behavior if you need it. And you can register multiple controllers for the same entity type.