An instant solution is to use a unique string, e.g. A1wQz!, as part of the comment of every rule in group 1, and another unique string, e.g. B2tFe-, as part of the comment of every rule in group 2. Once you do that,
/ip firewall filter enable [find comment~"A1wQz!"] ; /ip firewall filter disable [find comment~"B2tFe-"]
will switch over from group 1 rules to group 2 rules, and
/ip firewall filter enable [find comment~"B2tFe-"] ; /ip firewall filter disable [find comment~"A1wQz!"]
will switch back.
Or, if you don't mind losing some CPU cycles on every single packet, you can use two action=jump rules as the very first ones in each chain (input, forward, maybe output) matching on src-address-list or dst-address-list:
/ip firewall address-list
add list=use-group-2 address=0.0.0.0/0 disabled=yes
/ip firewall filter add
chain=forward action=jump jump-target=forward-group-1 dst-address-list=!use-group-2
chain=forward action=jump jump-target=forward-group-2 dst-address-list=use-group-2
chain=forward-group-1 action=accept connection-state=established,related,untracked
chain=forward-group-2 action=accept connection-state=established,related,untracked
While the address-list item is disabled, rules in group 1 are used, while it is enabled, rules in group 2 are used. Always activate safe mode before switching between groups in chain input, so that you don't need to reset the device to defaults if you lock yourself out.
Once you find out for yourself that the few first rules in the default firewall configuration cannot be optimized any more, you can move the choice between the two groups past them, so you won't spend the extra CPU on each packet but only on the initial one of each new connection.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.