[EI-110] Wider edge_integrations_enabled checks

[jazzsequence]

The edge_integrations_enabled check checks headers sent, but if we aren't sending headers (like we are in the admin) then this will return false.

This PR checks returned geo and interest headers first, then checks the headers that are sent (and if they get data back).

In most cases, checking sent headers and their returned responses will not be checked, as we skip it if we have geo or interest headers. However, if custom headers were sent, these will be checked after geo and interest. This is resolved by the addition of a new filter, pantheon.ei.get_custom_headers which should be used in a third-party function that returns the custom header data (similar to Geo\get_geo and Interest\get_interest) which will hook the third party code into edge_integrations_enabled.

[CdrMarks]

Is it possible to use a filter to remove geo or interest such that these will not work correctly?

[jazzsequence]

You can filter both things.
https://github.com/pantheon-systems/edge-integrations-wordpress-sdk/blob/main/docs/geo.md#pantheoneiparsed_geo_data
and
https://github.com/pantheon-systems/edge-integrations-wordpress-sdk/blob/main/docs/interest.md#pantheoneiparsed_interest_data

That's actually how the tests are working. However, I would expect if I was filtering either of those that I would be aware that I was potentially breaking/overriding the edge_integrations_enabled value.

[CdrMarks]

This is somewhat related to my question above.

[jazzsequence]

Yep, both of those are there to ensure that when testing, we're not inheriting filtered values from other places (since we're not using a real WPUnit environment that clears out the instance in between test runs).

I defer to my initial statement that if you're filtering that stuff, you're modifying the data intentionally, so ymmv, but if there's a place in the documentation that we could be more explicit about the side effects, I'd be happy to update.