memory leak caused by many origin

## Issue Description

我的用法是这样的，服务A调用服务B（服务C、D、E、F....都可能会调用B），在服务B中用了 `SphU.entry(resourceName,ResourceTypeConstants.COMMON_RPC, EntryType.IN)`，这本身没有问题。但近期给B服务的其他组件也加上了Sentinel，比如调用DB、redis、甚至是调用其他服务的时候（都在B里面）。上线之后内存增长非常快，基本上高峰期10分钟就会一次full gc，young gc的频次也变得频繁了。

Type: *bug report* or *feature request*

### Describe what happened (or what feature you want)

我看了一下，具体的原因，应该是有多个上游的时候，origin数量过多，导致MetricNode数量过多。但感觉里面有一些设计不太合理的地方，比如以下链路，A->B->redis、DB、....等其他资源。按照我的理解，B有多个上游，通过设置origin进行区分，问题不大。但是B去调用其他资源的时候，由于属于A->B的子链路，会导致B->redis、B->DB也会带上origin，但事实上，这些子链路（EntryType.OUT的时候）的origin应该是自己，这个时候去区分origin没有任何意义，反而会增加统计的成本。

### Describe what you expected to happen
1. 是否可以调整为，EntryType为IN的时候才统计origin，避免origin的上下文信息传递到OUT的调用模块。比如以下的代码（不完全是这里，只是粗略的看了 一下，应该还有其他地方要调整）


改为


2. 当resource规则没有配置时，是否可以不记录MetricNode

### Tell us your environment
1.8.0

Start with SphU.entry and trace how origin is propagated for EntryType.IN and EntryType.OUT. Inspect MetricNode creation and the behavior when no resource rule is configured. Done means unnecessary origin distinctions and MetricNode growth are avoided without the reported memory and GC pressure.

Written by the indexing model from the issue text.