feat(exporter) export enterprise license info

[fffonion]

# HELP kong_enterprise_license_expiration Unix epoch time when the license expires, the timestamp is substracted by 24 hours to avoid difference in timezone
# TYPE kong_enterprise_license_expiration gauge
kong_enterprise_license_expiration 1836691200
# HELP kong_enterprise_license_features License features features
# TYPE kong_enterprise_license_features gauge
kong_enterprise_license_features{feature="ee_plugins"} 1
kong_enterprise_license_features{feature="write_admin_api"} 1
# HELP kong_enterprise_license_signature Last 32 bytes of the license signautre in number
# TYPE kong_enterprise_license_signature gauge
kong_enterprise_license_signature 4.0089516347127e+40

[mikefero]

Looks good, just one small nit.

I did notice that dataplanes, admin_seats, product_subscription, and support_plan are not being parsed and added to the metrics collection which could add some value; don't think customer, license_key, and license_creation_date would add value though.

[hbagdi]

This is Enterprise-specific code. I'm not sure why this is included here in an Open-source repository. I'd advise against including this here. And if we do decide to do this, please make sure you include the why in your commit message.

[mikefero]

Good call; didn't even notice that. This should be moved into Enterprise code base instead.

[fffonion]

@hbagdi @mikefero although this PR invokes enterprise code but there's no new enterprise feature being implemented here. if we want to move this to EE codebase, it will become either a EE fork, which won't work with the status_api model, or a dynamically loaded lua module that introduces headaches.

[fffonion]

i agree we can add dataplanes . as admin_seats, product_subscription, and support_plan basically descibes the license but not controls the funcionality of kong (correct me if i'm wrong), i don't think it make much sense to monitor them.

[hbagdi]

@hbagdi @mikefero although this PR invokes enterprise code but there's no new enterprise feature being implemented here. if we want to move this to EE codebase, it will become either a EE fork, which won't work with the status_api model, or a dynamically loaded lua module that introduces headaches.

I understand the pain here but that's really the right thing to do. You could add hooks tot he OSS code-base to ease with the pain.

[gszr]

IMO this is not necessarily the 'wrong' approach, as there is no sensitive code being added -- the code here simply calls an enterprise-specific API. Moving it over to the enterprise side might add unnecessary maintenance burden.