MINOR: Move DeleteGroupsResult to internals package.

[smjn]

• DeleteGroupsResult was introduced in the PR KAFKA-18629: ShareGroupDeleteState admin client impl. #18928 to serve as common parent class of DeleteConsumerGroupsResult and DeleteShareGroupsResult since the impl of the child classes is almost identical.
• However, since DeleteGroupsResult is abstract and not for direct consumption, it makes sense to not keep it in public packages per the comment KAFKA-18629: ShareGroupDeleteState admin client impl. #18928 (comment).
• In this PR, we perform this refactor to move it to internals package.

[AndrewJSchofield]

@junrao Is this better? It seems to me that we now have two public classes inheriting from a class in the internals package. Would you prefer that we remove the inheritance and just duplicate the code into DeleteConsumerGroupsResult and DeleteShareGroupsResult?

[ijuma]

I don't think we should do this change for the reason @AndrewJSchofield mentioned. Parent classes of public classes need themselves to be public.

[junrao]

@AndrewJSchofield: DeleteGroupsResult wasn't included as part of the public interface in the original KIP. Do you think that it makes sense to include it in the public interface?

[AndrewJSchofield]

@AndrewJSchofield: DeleteGroupsResult wasn't included as part of the public interface in the original KIP. Do you think that it makes sense to include it in the public interface?

To be honest, I think this area is ripe for a bit of rationalisation, not just in terms of these classes. We probably ought to have Admin.deleteGroups(DeleteGroupsOptions) to go alongside Admin.listGroups(ListGroupsOptions), rather than a proliferation of Admin.deleteXXXGroups methods. Then you could specify a group type optionally with the deletion operation, and Admin.deleteShareGroups() would be removed and Admin.deleteConsumerGroups() would be deprecated. I wish I'd realised when I did KIP-1043.

I will discuss with @dajac because I'd like to get him on board before proposing a change like this.