How to use batadv gw_mode feature

I have a network of about 15 devices forming a mesh using batman advanced and 80211s. Every device provides a wifi-AP and the wifi ap is bridged to the batadv soft interface bat0. Currently, there is only one device that is used as a gateway to the internet. This device also serves DHCP. Now I would like other devices to provide internet access too. The gw_mode feature of batman-adv seems to be perfect for this:
When a non-mesh client sends a DHCP request into the mesh, batman-advanced transforms it into a unicast to the gateway it has selected for the client and the gatway then responds with its own address as default-gatway.

Here is my problem: When a client is connected directly to a gateway-device, it will always be able to reach the DHCP-server of that device, since batadv is not in between to filter the requests. So the client will always get an offer from that gatway and likely chooses it as their default route, even when it is a very slow LTE-connection. What I would like to happen is that the client only reaches the the DHCP-server that was chosen by batadv.

All solutions I could think of so far seem to be overcomplicated. One would be to create a second soft interface, bat1 on the gateway-nodes and run the DHCP-server on that, thus having two batadv-nodes on one device. Then I would somehow need to connect the two nodes inside the device, maybe by configuring loopback device as hardif for both softifs.
I find it hard to believe that it has to be so complicated. I'm probably missing someting. So I ask here for help.

Check out LibreMesh

In LibreMesh this is solved by using a special anycast IP- and mac-address which is the same for every router. Every router serves DHCP and offers the anycast address as the default gatway. The packets are then routed with babeld towards the best gateway. This is a great solution for large networks that have multiple layer 2 'clouds'.

However, it appears a little bit to complex for my use case. I would be happier with a solution that doesn't require bridge filter rules and a second routing protocol.