Add required fields for custom TLS

[caiges]

Change summary

Add creation and deletion of custom TLS configurations. This is building up changes required to fully support custom TLS configurations in the Fastly Terraform Provider.

All Submissions:

• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?

New Feature Submissions:

• Does your submission pass tests?

Changes to Core Features:

• Have you written new tests for your core changes, as applicable?
• Have you successfully run tests with your changes locally?

User Impact

There shouldn't be any impact to existing users.

Are there any considerations that need to be addressed for release?

• Some of this functionality may require Fastly to enable for account-specific features.
• Public type structure may not be desired shape.

[anthony-gomez-fastly]

LGTM! thank you!

[anthony-gomez-fastly]

@caiges looks great, please add a changelog entry

[caiges]

@anthony-gomez-fastly Added alongside the other unreleased change.

[kpfleming]

Unfortunately we cannot make these changes as they are, because these fields are only available to a subset of customers who have additional TLS platform features enabled on their accounts. The API endpoints are the same for both normal and enhanced TLS features, but the go-fastly functionality cannot be the same because the API will reject requests that include attributes which are not supported by the normal accounts. This is an artifact of an API design decision which was made long ago and predates everyone involved today :-)

For this to be supported, go-fastly (and the CLI/Terraform provider) will have to have a parallel set of functions which are only used by customers who have access to the enhanced TLS features. In addition since these features are not part of our public documentation (at least that was true the last time I checked), we technically should not even support them in go-fastly. That part of the discussion will need to involve the TLS engineering team and our Product Management team.

[caiges]

This is an artifact of an API design decision which was made long ago and predates everyone involved today :-)

😆 I am all too familiar with this phenomenon.

we technically should not even support them in go-fastly. That part of the discussion will need to involve the TLS engineering team and our Product Management team.

My work here and in a fork of the provider was based on these fields being optional but semi-private fields tend to become the public API in practice so can also understand this too.

[kpfleming]

If you want to pursue this that would certainly be welcome, but as I mentioned previously the approach would have to be creating a new set of API functions (which use the SPP label to distinguish them from the regular functions) so that the existing functions continue to operate as they do now.