feat(web-vitals): collect all vitals metrics by default

[joseph-embrace]

What problem is this solving?

We want to start collecting all web vitals metrics by default. Right now we're only collecting the core web vitals.

Short description of changes

• Collect FCP and TTFB on top of the core web vitals.

How has this been tested?

• Automated tests.

Checklist

• Documentation added
• Tests added

[github-actions]

Chrome DevTools Protocol Tracing (Script: 107.45ms, Heap: 14.34MB)

	Number of Requests	Size of Requests	Script Duration	Task Duration	Heap Used Size
Requests	+3 requests	+30.00 KB
Page Loaded			+16.58 ms	+12.59 ms	+1.05 MB
Generate 100 fetch requests			+23.12 ms	+113.40 ms	+1.78 MB
Generate 100 XHR requests			+41.24 ms	+119.14 ms	+1.89 MB
Click 100 buttons and generate 100 logs			+15.91 ms	+19.21 ms	+3.24 MB
Throw a 100 exceptions			+2.57 ms	+25.82 ms	+2.88 MB
End Session			+8.04 ms	+4.95 ms	+3.50 MB
Total	+3 requests	+30.00 KB	+107.45 ms	+295.12 ms	+14.34 MB

Lighthouse (Script Eval: 123.94ms)

	Difference	Description
Total Blocking Time	+12 ms	Difference in Total Blocking Time: Sum of all time periods between FCP and Time to Interactive, when task length exceeded 50ms, expressed in milliseconds. Learn more about the Total Blocking Time metric.
Main Thread Time	+111.51 ms	Difference in Main Thread Time: Consider reducing the time spent parsing, compiling and executing JS. You may find delivering smaller JS payloads helps with this. Learn how to minimize main-thread work
Script Evaluation Time	+123.94 ms	Difference in Script Evaluation Time: Consider reducing the time spent parsing, compiling, and executing JS. You may find delivering smaller JS payloads helps with this. Learn how to reduce Javascript execution time.

[jpmunz]

looks like we briefly use this as an example in the README that we should probably switch to something else:

embrace-web-sdk/packages/web-sdk/README.md

Line 259 in 70c310a

trackingLevel: 'all'

[overbalance]

This is a breaking change for any users expecting the core group. Any concerns there? If you decide to drop trackingLevel, there are a few more instances in the codebase.

[jpmunz]

This is a breaking change for any users expecting the core group. Any concerns there? If you decide to drop trackingLevel, there are a few more instances in the codebase.

I think this would be fine for a minor release, it's similar to adding in a new instrumentation that will start collecting more data by default. The trackingLevel param can be kept as part of the config type to avoid breaking existing usages but marked as deprecated