Feature: when use tcc fence, add a config to enable empty rollback

[pengten]

• I have registered the PR changes.

Ⅰ. Describe what this PR did

在TCC注解中添加一个配置去开关空回滚的拦截能力, 具体场景可在 #4530 中了解。该PR希望大佬们可以一起交流讨论，提供一些建议

Ⅱ. Does this pull request fix one issue?

fixes #4530

Ⅲ. Why don't you add test cases (unit test/integration test)?

Ⅳ. Describe how to verify it

Ⅴ. Special notes for reviews

[Bughue]

一阶段预计有n个参与者RM，但是第m个参与者prepare失败，产生全局rollback。这个时候的rm分3种情况
1、有（n-m）个RM没有prepare，因为fence表没有记录，他们的rollback会被直接拒绝。
2、有（m-1）个RM进行了prepare，fence表里面有status=1的记录，他们的rollback会正常进行。
3、第m参与者自身prepare失败，导致fence表一起回滚所以没有记录，他的rollback会被直接拒绝。

这个pr处理的是3对吗？看pr里面好像区分不了1和3，所以是业务自行判断？

[pengten]

一阶段预计有n个参与者RM，但是第m个参与者prepare失败，产生全局rollback。这个时候的rm分3种情况 1、有（n-m）个RM没有prepare，因为fence表没有记录，他们的rollback会被直接拒绝。 2、有（m-1）个RM进行了prepare，fence表里面有status=1的记录，他们的rollback会正常进行。 3、第m参与者自身prepare失败，导致fence表一起回滚所以没有记录，他的rollback会被直接拒绝。

这个pr处理的是3对吗？看pr里面好像区分不了1和3，所以是业务自行判断？

是针对第3种情况，至于第1种情况中没有prepare的RM，因为没有注册分支所以不会参与二阶段，不用区分也没问题。

[Bughue]

一阶段预计有n个参与者RM，但是第m个参与者prepare失败，产生全局rollback。这个时候的rm分3种情况 1、有（n-m）个RM没有prepare，因为fence表没有记录，他们的rollback会被直接拒绝。 2、有（m-1）个RM进行了prepare，fence表里面有status=1的记录，他们的rollback会正常进行。 3、第m参与者自身prepare失败，导致fence表一起回滚所以没有记录，他的rollback会被直接拒绝。
这个pr处理的是3对吗？看pr里面好像区分不了1和3，所以是业务自行判断？

是针对第3种情况，至于第1种情况中没有prepare的RM，因为没有注册分支所以不会参与二阶段，不用区分也没问题。

理解。不过这种prepare失败的rollback和常规tcc的rollback(prepare成功)的含义不太一样，这种更像是本地事务的一致性，做在这里会不会有点奇怪

[pengten]

一阶段预计有n个参与者RM，但是第m个参与者prepare失败，产生全局rollback。这个时候的rm分3种情况 1、有（n-m）个RM没有prepare，因为fence表没有记录，他们的rollback会被直接拒绝。 2、有（m-1）个RM进行了prepare，fence表里面有status=1的记录，他们的rollback会正常进行。 3、第m参与者自身prepare失败，导致fence表一起回滚所以没有记录，他的rollback会被直接拒绝。
这个pr处理的是3对吗？看pr里面好像区分不了1和3，所以是业务自行判断？

是针对第3种情况，至于第1种情况中没有prepare的RM，因为没有注册分支所以不会参与二阶段，不用区分也没问题。

理解。不过这种prepare失败的rollback和常规tcc的rollback(prepare成功)的含义不太一样，这种更像是本地事务的一致性，做在这里会不会有点奇怪

没想到其他合适的处理方式，现在问题就是本地事务已经无法解决了，才需要利用分布式事务解决。 其实这个fencelog说是防悬挂，但实际上是一起做了防悬挂和防空回滚的，这里只不过是提供一种将空回滚拿出来单独控制的能力。 而且我理解在分布式事务中，参与了事务一阶段的分支都应该有权利选择是否参与事务的二阶段。

当然也可以通过RM的钩子来监听全局事务状态进行一些补偿操作，但是如果RM正常收到了二阶段回滚，在钩子里还会再处理一次。 钩子应该只处理一些和全局事务一致性弱相关的事宜，比起放钩子里感觉这个方案更合适一些

[CLAassistant]

All committers have signed the CLA.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
0 out of 2 committers have signed the CLA.

❌ pengten
❌ a364176773
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[codecov-commenter]

Codecov Report

Merging #4532 (265c139) into develop (53d65bf) will decrease coverage by 0.01%.
The diff coverage is 0.00%.

@@              Coverage Diff              @@
##             develop    #4532      +/-   ##
=============================================
- Coverage      49.35%   49.34%   -0.02%     
  Complexity      4073     4073              
=============================================
  Files            731      731              
  Lines          25465    25471       +6     
  Branches        3156     3157       +1     
=============================================
  Hits           12569    12569              
- Misses         11559    11565       +6     
  Partials        1337     1337              

Impacted Files	Coverage Δ
...ommon/src/main/java/io/seata/common/Constants.java	100.00% <ø> (ø)
...src/main/java/io/seata/rm/tcc/TCCFenceHandler.java	0.00% <0.00%> (ø)
.../main/java/io/seata/rm/tcc/TCCResourceManager.java	0.00% <0.00%> (ø)
...a/rm/tcc/interceptor/ActionInterceptorHandler.java	11.90% <0.00%> (-0.15%)	⬇️