Removed ref-getter methods from "schedule" API

[bvaughn]

First two steps of #13559:

• Replace the __getInteractionsRef and __getSubscriberRef methods with direct exports (__interactionsRef and __subscriberRef) and update the ScheduleTracking UMD fork.
• Remove __getInteractionsRef and __getSubscriberRef from the schedule/tracking UMD dev and prod bundles since it's not part of the public API.

I tested the packaging and tracking fixtures, as well as the "suspense" demo app, and hand-inspected the react, react-dom, and schedule NPM bundles. All seemed in order.

[pull-bot]

React: size: -0.4%, gzip: -0.1%

Details of bundled changes.

Comparing: fb88fd9...3c2a934

react

File	Filesize Diff	Gzip Diff	Prev Size	Current Size	Prev Gzip	Current Gzip	ENV
react.development.js	-0.4%	-0.4%	83.77 KB	83.44 KB	22.73 KB	22.63 KB	UMD_DEV
react.production.min.js	-0.4%	-0.1%	9.59 KB	9.55 KB	3.96 KB	3.96 KB	UMD_PROD

schedule

File	Filesize Diff	Gzip Diff	Prev Size	Current Size	Prev Gzip	Current Gzip	ENV
schedule.development.js	n/a	n/a	0 B	19.17 KB	0 B	5.74 KB	UMD_DEV
schedule.production.min.js	n/a	n/a	0 B	3.16 KB	0 B	1.53 KB	UMD_PROD
schedule-tracking.development.js	-2.1%	-4.1%	10.83 KB	10.61 KB	2.62 KB	2.52 KB	NODE_DEV
schedule-tracking.production.min.js	-5.8%	-1.3%	765 B	721 B	386 B	381 B	NODE_PROD
schedule-tracking.profiling.min.js	+12.9%	0.0%	2.89 KB	3.26 KB	997 B	997 B	NODE_PROFILING
ScheduleTracking-dev.js	-2.1%	-5.0%	10.43 KB	10.21 KB	2.35 KB	2.23 KB	FB_WWW_DEV
ScheduleTracking-prod.js	-5.9%	-0.7%	949 B	893 B	428 B	425 B	FB_WWW_PROD
ScheduleTracking-profiling.js	+0.2%	-1.7%	6.8 KB	6.81 KB	1.25 KB	1.23 KB	FB_WWW_PROFILING

Generated by 🚫 dangerJS

[sebmarkbage]

The ref object thing is pretty OCaml/React specific.

Would it make sense to just have one object with two mutable fields on it? One field for interactions and one field for subscribers?

[bvaughn]

Would it make sense to just have one object with two mutable fields on it? One field for interactions and one field for subscribers?

Sure, that could work too. I don't have a strong preference.

I think we'll probably want to revisit these two properties before a 1.0 release anyway, regarding our conversation yesterday. Sounds like they may be more appropriate to expose as an "advanced API" rather than "private".

I guess I could move them behind an advanced wrapper? I just don't know what to call the thing.

Let's make that change in a future commit. 😄