feat: add support for specifying real-ip-filter in DNS

[HEUDavid]

DNS 支持 real-ip-filter 指定

fake-ip 白名单模式
当 fake-ip-filter 和 real-ip-filter 同时匹配时，fake-ip-filter 优先级更高。
如果都没有匹配到规则，则返回 fake-ip。

例：

• 如果广告域名 (www.ad.com) 同时满足 fake-ip-filter:AD 和 real-ip-filter:cn，则返回 fake-ip。
• 如果被墙域名 (wiki.metacubex.one) 都没匹配到，默认返回 fake-ip。

dns:
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter-mode: whitelist
  fake-ip-filter:
    - rule-set:anti-AD
    - geosite:gfw
  real-ip-filter:
    - geosite:cn
    - rule-set:douyin

MacOS 自测符合预期，其他平台未做测试。

(base) ➜  ~ nslookup www.google.com 127.0.0.1 -port=1053
Server:		127.0.0.1
Address:	127.0.0.1#1053

Name:	www.google.com
Address: 198.18.0.6

(base) ➜  ~ nslookup www.baidu.com 127.0.0.1 -port=1053
Server:		127.0.0.1
Address:	127.0.0.1#1053

www.baidu.com	canonical name = www.a.shifen.com.
Name:	www.a.shifen.com
Address: 157.148.69.74
Name:	www.a.shifen.com
Address: 157.148.69.80

(base) ➜  ~ nslookup wiki.metacubex.one 127.0.0.1 -port=1053
Server:		127.0.0.1
Address:	127.0.0.1#1053

Name:	wiki.metacubex.one
Address: 198.18.1.198

(base) ➜  ~ route get wiki.metacubex.one
   route to: 198.18.1.198
destination: 198.18.0.0
       mask: 255.255.0.0
    gateway: 198.18.0.1
  interface: utun9
      flags: <UP,GATEWAY,DONE,STATIC,PRCLONING>
 recvpipe  sendpipe  ssthresh  rtt,msec    rttvar  hopcount      mtu     expire
       0         0         0         0         0         0      1500         0

[HEUDavid]

使用场景，见讨论：#1479 (comment)

[Fddh2012]

我认为这个功能不应该只是用来解决所谓的广告问题，
如果更新成现在这样的逻辑的话感觉fake-ip-filter-mode其实是不需要的。
因为已经有返回fake-ip和real-ip的两条路径了。
在这种情况下，不能被匹配到这两条路径中的其他域名我觉得就应该直接上一条兜底路径。
即先匹配real-ip，再匹配fake-ip, 其余的都直接fake-ip，但是这样看起来又多此一举了。
所以我的意见是：直接看fake-ip-filter和real-ip-filter的先后顺序，在后面的做兜底；即如果real-ip-filter在前，那么fake-ip兜底，如果fake-ip-filter，那real-ip兜底。
这样一来至于fake-ip-filter-mode就不需要了。或者像rules那样直接

• RULE-SET,Google_CN,real-ip
• RULE-SET,Google_domain,fake-ip
• MATCH,fake-ip/real-ip

[HEUDavid]

我认为这个功能不应该只是用来解决所谓的广告问题， 如果更新成现在这样的逻辑的话感觉fake-ip-filter-mode其实是不需要的。 因为已经有返回fake-ip和real-ip的两条路径了。 在这种情况下，不能被匹配到这两条路径中的其他域名我觉得就应该直接上一条兜底路径。 即先匹配real-ip，再匹配fake-ip, 其余的都直接fake-ip，但是这样看起来又多此一举了。 所以我的意见是：直接看fake-ip-filter和real-ip-filter的先后顺序，在后面的做兜底；即如果real-ip-filter在前，那么fake-ip兜底，如果fake-ip-filter，那real-ip兜底。 这样一来至于fake-ip-filter-mode就不需要了。或者像rules那样直接

• RULE-SET,Google_CN,real-ip
• RULE-SET,Google_domain,fake-ip
• MATCH,fake-ip/real-ip

我也认为fake-ip-filter-mode是不需要的，如果管理员认可的话可以按你的想法，我如此改动是因为不想影响原有的特性。

[HEUDavid]

@wwqgtxx 好兄弟，麻烦review下，有意见的话可以修改 :)

[Fddh2012]

我认为这个功能不应该只是用来解决所谓的广告问题， 如果更新成现在这样的逻辑的话感觉fake-ip-filter-mode其实是不需要的。 因为已经有返回fake-ip和real-ip的两条路径了。 在这种情况下，不能被匹配到这两条路径中的其他域名我觉得就应该直接上一条兜底路径。 即先匹配real-ip，再匹配fake-ip, 其余的都直接fake-ip，但是这样看起来又多此一举了。 所以我的意见是：直接看fake-ip-filter和real-ip-filter的先后顺序，在后面的做兜底；即如果real-ip-filter在前，那么fake-ip兜底，如果fake-ip-filter，那real-ip兜底。 这样一来至于fake-ip-filter-mode就不需要了。或者像rules那样直接

• RULE-SET,Google_CN,real-ip
• RULE-SET,Google_domain,fake-ip
• MATCH,fake-ip/real-ip

我也认为fake-ip-filter-mode是不需要的，如果管理员认可的话可以按你的想法，我如此改动是因为不想影响原有的特性。

看群里有讨论了一下，break changing的话不会合并，最好是给fake-ip-filter-mode再加个rule模式，然后再套用上面这套装流程来处理。

[HEUDavid]

看群里有讨论了一下，break changing的话不会合并，最好是给fake-ip-filter-mode再加个rule模式，然后再套用上面这套装流程来处理。

这是仓库Maintainers的意见吗？
当前改动break changing是指？另外确定最终行为是

fake-ip-filter-mode: rule
fake-ip-filter:
- rule-set:anti-AD,fake-ip
- rule-set:my_proxy,fake-ip
- geosite:cn,real-ip
- MATCH:fake-ip/real-ip

还是与全局的rules对齐？

[Fddh2012]

看群里有讨论了一下，break changing的话不会合并，最好是给fake-ip-filter-mode再加个rule模式，然后再套用上面这套装流程来处理。

这是仓库Maintainers的意见吗？ 当前改动break changing是指？另外确定最终行为是

fake-ip-filter-mode: rule
fake-ip-filter:
- rule-set:anti-AD,fake-ip
- rule-set:my_proxy,fake-ip
- geosite:cn,real-ip
- MATCH:fake-ip/real-ip

还是与全局的rules对齐？

应该只在fake-ip-filter这个模块里处理好吧，和全局rules独立开来。