config: fix goroutine leak risk

[Yisaer]

Signed-off-by: Song Gao disxiaofei@163.com

What problem does this PR solve?

What is changed and how it works?

The SetTTLData may have goroutine leak as NewStringTTL would create an extra goroutine to do the gc work. When updating an existed key, we need to call the cancel function to close the extra goroutine.

// SetTTLData set temporary configuration
func (o *PersistOptions) SetTTLData(ctx context.Context, key string, value interface{}, ttl time.Duration) {
	if data, ok := o.ttl[key]; ok {
		data.Clear()
                // the goroutine would leak here
	}
	o.ttl[key] = cache.NewStringTTL(ctx, 5*time.Second, ttl)
	o.ttl[key].Put(key, value)
}

As the origin context is directly use the server context, this request fix it by replace a new context which is success from the server context and maintained its cancel function.

Release note

[JmPotato]

LGTM

[Yisaer]

/merge

[ti-srebot]

/run-all-tests

[disksing]

Why create cache.TTLString for each key, instead of use only 1 cache.TTLString for all keys?

[Yisaer]

For each configuration, they could have different ttl.

[ti-srebot]

cherry pick to release-4.0 in PR #3094