fix: support external plugins.

[shunjiazhu]

问题： 合并编译时，无法识别私有仓库中的插件，需要改为从go插件中拿到所有的插件。

备注： 额外提供一个开关来显式指定加载go插件，这样默认行为能和当前的ilogtail保持一致。

[shunjiazhu]

因为考虑到有些场景，比如文件采集，用不到go插件。所以做了一个开关load_plugin_base，这样行为可以和ilogtail 2.0上一个版本保持一致了，然后字节自己打包的产物可以确保这个参数为true。

[henryzhx8]

因为考虑到有些场景，比如文件采集，用不到go插件。所以做了一个开关load_plugin_base，这样行为可以和ilogtail 2.0上一个版本保持一致了，然后字节自己打包的产物可以确保这个参数为true。

嗯，但是出包的时候这个参数值是一定的，不能假定用户用或者用不到Go插件。对于第三方用户，如果他也有自己的私有插件，他还得记得把这个参数给强制打开。这种架构上的设置最好不要分叉。

[shunjiazhu]

因为考虑到有些场景，比如文件采集，用不到go插件。所以做了一个开关load_plugin_base，这样行为可以和ilogtail 2.0上一个版本保持一致了，然后字节自己打包的产物可以确保这个参数为true。

嗯，但是出包的时候这个参数值是一定的，不能假定用户用或者用不到Go插件。对于第三方用户，如果他也有自己的私有插件，他还得记得把这个参数给强制打开。这种架构上的设置最好不要分叉。

这个问题感觉可以通过更新一下脚本解决：

1. c++还是维护一个默认的插件集合
2. 如果检测到external_plugins，脚本注入这个开关。

因为完全移动到go之后，c++这边对插件进行编排这个能力是不是会丢失? 我们也有预期想共建core的这部分能力，还是蛮重要的

[henryzhx8]

因为考虑到有些场景，比如文件采集，用不到go插件。所以做了一个开关load_plugin_base，这样行为可以和ilogtail 2.0上一个版本保持一致了，然后字节自己打包的产物可以确保这个参数为true。

嗯，但是出包的时候这个参数值是一定的，不能假定用户用或者用不到Go插件。对于第三方用户，如果他也有自己的私有插件，他还得记得把这个参数给强制打开。这种架构上的设置最好不要分叉。

这个问题感觉通过更新一下脚本解决，

1. c++还是维护一个默认的插件集合
2. 如果检测到external_plugins，脚本注入这个开关。

因为完全移动到go之后，c++这边对插件进行编排这个能力是不是会丢失，我们也有预期想共建core的这部分能力，还是蛮重要的

你说的这个方案我觉得也是可行的，编译时注入，可能唯一的小缺点就是Go这边插件列表变了，C++部分也得重新编译，不过我理解iLogtail作为整体的话，全部重新编译也能接受。

[shunjiazhu]

因为考虑到有些场景，比如文件采集，用不到go插件。所以做了一个开关load_plugin_base，这样行为可以和ilogtail 2.0上一个版本保持一致了，然后字节自己打包的产物可以确保这个参数为true。

嗯，但是出包的时候这个参数值是一定的，不能假定用户用或者用不到Go插件。对于第三方用户，如果他也有自己的私有插件，他还得记得把这个参数给强制打开。这种架构上的设置最好不要分叉。

这个问题感觉通过更新一下脚本解决，

1. c++还是维护一个默认的插件集合
2. 如果检测到external_plugins，脚本注入这个开关。

因为完全移动到go之后，c++这边对插件进行编排这个能力是不是会丢失，我们也有预期想共建core的这部分能力，还是蛮重要的

你说的这个方案我觉得也是可行的，编译时注入，可能唯一的小缺点就是Go这边插件列表变了，C++部分也得重新编译，不过我理解iLogtail作为整体的话，全部重新编译也能接受。

我改了一下构建脚本，辛苦再看一下。