在测试obs simulcast推流时，发现chrome无法正常播放，
分析rtp ext扩展，发现是rtp mid ext未过滤导致，
zlmediakit在回复answer sdp时，已申明不支持mid扩展，
但是obs并未理会还是发送mid扩展。
根据answer sdp过滤rtp ext可兼容此问题。

__attribute__((packed)) 替换为 #pragma pack(push, 1)

simulcast推流时，在onRecvRtp函数中可能触发对totalReaderCount的调用，从而导致死锁。

bug触发条件：
1、obs whip 推流到zlm
2、关闭推流
3、zlm 未注销流

Co-authored-by: xia-chu <771730766@qq.com>

Make available the media_info variable for the class inherited from WebRtcSession and HttpSession. (#2505 #2461)

通过whip/whep 回复http头中的Location url进行删除资源
新增delete token随机数实现删除鉴权

最后一个连通的候选地址会被赋值并锁定为_selected_session，如果之前的候选地址再发送数据，将通过_selected_session回复，导致无法切换为旧的候选地址。

因WebRtcPlayer中使用RtspMediaSource的共享指针，特定情况下引起媒体注销无法触发的问题。

- 重现步骤
    在ZL的webrtc demo页面推流
    浏览器打开如下html
    webrtc.html
    关闭推流器页面,推流器停止推流
    webrtc.htm浏览器console->network将观察到：即使推流停止，但webrtc sdp请求一直能成功获取sdp，且流媒体一直不注销

- 原因
        因为每个WebRtc 播放 SDP请求都会产生 WebRtcPlayer，产生RtspMediaSource的共享指针，产生强引用。
        而DTLS超时释放需要一定的时间，WebRtcPlayer销毁需要超时。如果请求sdp的时间足够短，强引用会一直存在。将永远无法触发媒体注销

- 场景
        webrtc播放存在重试，但是udp不通。DTLS无法创建
        有人对ZLM执行恶意攻击，短时间内不断请求SDP但是不建立WebRTC通信