Support destination filters for device mode action destinations

[danieljackins]

This PR allows destination filters to work with action destinations, by adding destination middleware support to them.

This change was tested by adding destination filters to an action destination and making sure events and properties were dropped properly.

[x] I've included a changeset (psst. run yarn changeset. Read about changesets here).

[changeset-bot[bot]]

🦋 Changeset detected

Latest commit: 91f0d8e63fe6a2fbb1a047b3146f8e0f18129b77

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@segment/analytics-next	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[danieljackins]

Overall I think this looks great, excited to see this middleware support added to action destinations!

Things I wanted to check:

1. We may need to move alternativeNames to the plugin interface then include it in our checks here: https://github.com/segmentio/analytics-next/blob/9c935795ea962c17a869d6d8143617b98e7e29a2/packages/browser/src/core/queue/event-queue.ts#L236-L239

   This way if someone is currently disabling/enabling based on the current plugin name (like FullStory (actions) trackEvent) it still works.

2. Can we apply the above logic for logging/metrics as well?

3. I commented that we should only apply destination filters on destination plugins - wonder if that should apply for all destination middleware as well. What are your thoughts there given action destinations can have non-destination actions.

1. Done!
2. Not exactly sure what you're getting at here
3. I think it would be safer to not have that restriction just in case they're trying to use them on 'enrichment' actions or something else

[chrisradek]

2. Not exactly sure what you're getting at here

The context keeps logs/stats about which plugins were ran. Currently you can see which actions are ran and some stats about them. With these changes I think we'll see the wrapper plugin's name instead, so Fullstory instead of Fullstory (actions) trackEvent - also makes it look like we're running the same plugin multiple times if a destination has more than 1 action.

from our dev environment: