remove unused models

[fivetran-reneeli]

PR Overview

This PR will address the following Issue/Feature:
#10
This PR will result in the following new package version: v0.4.0

Breaking change since this removes some models from the schema.

Please provide the finalized CHANGELOG entry which details the relevant changes included in this PR:

• Removes the following models that are unused downstream, along with their related files and mentions.
  • stg_twilio__address
  • stg_twilio__incoming_phone_number
  • stg_twilio__outgoing_caller_id

PR Checklist

Basic Validation

Please acknowledge that you have successfully performed the following commands locally:

• dbt run –full-refresh && dbt test
• [na] dbt run (if incremental models are present) && dbt test

Before marking this PR as "ready for review" the following have been applied:

• The appropriate issue has been linked, tagged, and properly assigned
• All necessary documentation and version upgrades have been applied
• docs were regenerated (unless this PR does not include any code or yml updates)
• BuildKite integration tests are passing
• Detailed validation steps have been provided below

Detailed Validation

Please share any and all of your validation steps:

Not much validation since these models were not used in the first place, but just ensuring that the models are removed in the documentation and in any mentions downstream.

If you had to summarize this PR in an emoji, which would it be?

💃

[fivetran-reneeli]

our standard way would be twilio__using_usage_record, but then I should also update using_twilio_call and using_twilio_messaging_service, which would require users who already have those variables configured to change it, which would be more of a hassle customer-experience wise.

[fivetran-reneeli]

As discussed internally, it makes sense to keep the unused staging models if they're not being run and materialized via the end models in Quickstart. We can keep them here so that users who may be only using the respective staging models can still access them, with no risk for errors downstream. As such, I'll remove this PR and open a separate one just for adding the disable config for usage_record.