feat: enhance eventbus with service_event

[qiankunli]

No description provided.

[ealyn]

重试中（甚至包括运行中）都归到init，有点反直觉，也不利于追踪，我看区分出来并不难？

[qiankunli]

retry_count > 1即表示重试。独立一个状态也可以，不过scanEvents 那个地方就略微复杂些

[ealyn]

那要不ServiceEventStatusInit换个名字，pending如何

[ealyn]

新机制不需要一个数字自增id了，要不删了？主键就用idx_service_event_id

[qiankunli]

这个是目前略微玄学的一点，不要自增id，TestEventBusConcurrent 中ConsumeConcurrent=1时，无法保证 事件消费的有序性，可能是scanEvent 得到的顺序可能不同。

[qiankunli]

原因找到了，在getScanEvents 有下面一段逻辑

eventOffset := int64(0)
lastServiceEvent := &ServiceEventPO{}
if err := e.db.Where("service = ?", e.serviceName).
  Order("event_id").Last(lastServiceEvent).Error; err != nil {
    if !errors.Is(err, gorm.ErrRecordNotFound) {
	return nil, err
    }
}
if lastServiceEvent.EventID > 0 {
    eventOffset = lastServiceEvent.EventID
}

在去掉id 自增主键以 service+event_id 为主键之后，查询sql是

 SELECT * FROM `ddd_domain_service_event` WHERE service = 'test_concurrent' ORDER BY event_id,`ddd_domain_service_event`.`service` DESC LIMIT 1;

这与 下面sql的执行结果是截然不同的（下面的sql 给结果是对的），估计是order by 时event_id 在前导致无法使用主键索引（主键索引是service+event_id）

 SELECT * FROM `ddd_domain_service_event` WHERE service = 'test_concurrent' ORDER BY `ddd_domain_service_event`.`service`,event_id DESC LIMIT 1;

此外，gorm First 和 Last 默认会给order 带上主键。
也因此，使用service+event_id 索引 + first/last 语句时，就不能额外再指定 Order("event_id")，或者说必须保持gorm order里的内容必须与主键索引的创建顺序一致（或者说不能相互影响），否则会影响代码逻辑正确性，这一细节很容易被遗忘

[ealyn]

checkPrecedingEvent会保证有序，db返回无序也没关系

[qiankunli]

但是对 getScanEvents 逻辑是有影响的。gorm 的first 和 last 语句（哪怕指定了order 字段）会自动带上对主键字段的排序，进而导致有时first 和 last返回的记录跟代码直觉不符，所以个人感觉不必为了省个字段而去掉主键id。