To be able to request membership in a group, a user must have the permissions to add or remove members of that group. These permissions can’t be granted separately. In your case, you need to create a Business Unit that will contain all security groups except built-in groups (e.g. Administrators) and a Security Role assigned over this Business Unit, that will allow members of the Domain Users group to modify the Member property of Group objects.
Then, you will need to set up an approval step. A Business Rule that triggers Before adding a member to a group and sends the operation for approval to the Owner of the target group's OU should be used for this purpose. Also, this Business Rule should have a If the initiator is not %member% condition that will check whether a user is requesting membership for someone else, and will cancel the operation if they are. Optionally, you can make an exclusion for OU owners and allow them adding other members by their own initiative. The Business Rule should be assigned over the same Business Unit (the one which contains all security groups).
To prevent users from removing group members they are not authorized to remove, you need another Business Rule that triggers Before removing a member from a group. This rule will have a If PowerShell script returns true condition that will check whether the initiator of the Remove member operation is the owner of the OU where the group is located, and cancel the operation if they aren’t.
To expose the feature, you need to add the Add to group action to the Web Interface for end users and select Always perform for the current user in the Member Selection section, so that users will be able to request membership only for themselves.
It is highly recommended to use two separate Web Interfaces for end users and for OU owners. This way you will be able to disable all Web Interface elements that allow adding or removing group members and leave only the dedicated Add to group action for simplicity. To be specific, you can hide the Add members operation and customize forms for viewing and editing groups to hide Add and Remove buttons in the Members section.
If the same Web Interface is used, hiding the operation and the buttons for end users will also hide them for OU owners. It is not necessary to hide them though, as the logic of who can add/remove members is controlled by Business Rules.
If you need further guidance on how to implement this architecture, please, describe the desired workflow and permissions in all the possible details.
There is also an alternative approach, which is more complicated and requires an additional Scheduled Task, a Custom Command, a dynamic Business Unit and a PowerShell script. The only benefit of this approach is that it will be easier to hide elements of the Web Interface if you plan on using the same interface for end users and OU owners.