feat: Add optional feature_type member to the SubscriptionEntitlemet model

[ole-magnus]

Context

A typical use case for me is to check the value when fetching SubscriptionEntitlement. One example API call:

import { ChargeBee } from 'chargebee-typescript';
const chargebee = new Chargebee();
chargbee.configure({ ... });

const result = await this.chargebee.subscription_entitlement
      .subscription_entitlements_for_subscription(subscriptionId)
      .request();

return result.list.some((entry: Result) => {
      const { feature_id, value } = entry.subscription_entitlement;
      return (
        feature_id === featureId &&
        this.entitlementValueCorrespondsToAccess( // function to check values
          entry.subscription_entitlement['feature_type'], // this does not exist in the type definitions
          value,
        )
      );
    });

The value heavily depends on the feature_type. E.g. value is a string representation of an integer, let's say "5", when feature_type is QUANTITY. In this scenario, I might want to parseInt(value, 10) in order to perform arithmetics on the value and so on. That said, I believe this can be unlimited as well so one should be careful here I would presume.

That said, the value might also be available, e.g. if the feature_type is "SWITCH". Then the formerly mentioned comparison of integers make no sense.

In summary, my point is the feature_type is essential when checking if a user has access. I'm not sure how this can be overlooked in this API and it makes me actually question if my approach is valid. Let me know if there are better ways to check access using features/entitlements.

Description of changeset

Adds feature_type to the SubscriptionEntitlement model as this is available in the API response. If this is always expected to be present, I would prefer to change this to non-optional.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud

[ole-magnus]

oh, just noticed this one now: #45.
Although I'm not sure it's correct to provide union values in lowercase as done there.

[ole-magnus]

@cb-khushbubibay @cb-yateshmathuria @cb-nithins @cb-thushitamariaselvan FYI