20210523ee逻辑的重构细节（river node层与river层）

思路上已经归纳出了新的框架思路，现在记录下细节：

对于river-node，无论是event还是error，是都不会存在(禁止)需要发送给前端的情况的,而部分error需要交给系统，从而让系统实现后续的工作流程
如各个panich，以及BAITSFILTER_LENAUTHFAIL(LENAUTHFAIL与HEADAUTHFAIL有很大不同，后者仅仅去记录下日志就可以了)

对于river来说就会开始存在两个需要发送给writer的event了，也就是各个RUN，各个PROACTIVE_DESTRUCT，而其他的无论是event还是error只要记录日志即可
这里重点再说一下，writer类型的river也会生成RUN和PROACTIVE_DESTRUCT，他们会在river内部被发送给eventbox，再被eventbox发送回来，重点来了：
正因为存在上述情况，于是为了确保这些“又被发送回来”的数据不会造成麻烦，writer必须被设计成确保这些来自eventbox数据不能被转化成“需要发送给前端的event”！
为了实现上述原则所有的writer需要被设计成，“所有内部所流动的数据”都严禁转化成需要被发送至前端的event
而所有的reader则并不需要遵循这一原则，想生成error就生成error（只记录还是需要扔给系统进行判断的均可）；想生成event就生成event(只记录的还是需要扔给前端的均可)
并不需要担心river-node内部发生的事件不会遵循这原则，因为上面已经总结过来，所有river-node都是不会产生需要发送给前端的事件的

对于所有river来说，无论是reader还是writer，RUN（构造）与PROACTIVE_DESTRUCT（析构）都是必须发送给前端的，但是他们均不是“由eventbox所发来的数据”，而是“需要发送至eventbox”的数据，因此无需多虑
需要重点留意writer所负责实现流动的数据，这些才是实实在在的包含着“由eventbox所发来的数据”
因此对于这些writer（也不用考虑其内部river-node的内传递状态），只需要考虑诸如其run函数内部这种存粹属于river层的情况，“在类似这里的场景”严禁生成新的需要被发送给客户端的event