Load D3.js library locally instead of CDN

Problem/Motivation

Currently, the D3.js library is loaded from a third-party CDN (Content Delivery Network). While CDNs offer convenience, this approach introduces several security and performance concerns that affect both site administrators and end users.

https://git.drupalcode.org/project/webform_statistics/-/blob/2.x/webform...

d3:
  version: 7.x
  js:
    https://cdn.jsdelivr.net/npm/d3@7: { type: external, minified: true }

Security Concerns:

• Content Security Policy (CSP) Violations: Loading external scripts requires loosening CSP headers, which increases the attack surface. Strict CSP policies that block external script sources will break functionality.
• Supply Chain Attacks: Third-party CDNs can be compromised, potentially serving malicious code to all sites that depend on them.
• Data Privacy: CDN requests expose user IP addresses and browsing behavior to third parties, which may conflict with GDPR, CCPA, or other privacy regulations.
• Subresource Integrity (SRI) Limitations: While SRI can help verify file integrity, it doesn't protect against all attack vectors and adds maintenance overhead when updating library versions.
• Trust Dependency: Organizations with strict security policies may not allow external script loading due to compliance requirements.

Performance Concerns:

• Single Point of Failure: If the CDN experiences downtime or is blocked in certain regions/networks, the functionality depending on D3.js will break.
• Additional DNS Lookup: Loading from an external domain requires an extra DNS resolution, adding latency.
• Connection Overhead: Establishing a new TLS connection to the CDN domain adds overhead compared to using existing connections to the origin server.
• Inconsistent Caching: Local hosting allows for better cache control and integration with the site's existing caching strategy.
• Offline/Intranet Usage: Sites operating in air-gapped environments or intranets cannot rely on external CDNs.

Steps to reproduce

1. Enable the webform_statistics.
2. Navigate to the webform_statistics repor.
3. Open browser developer tools (F12) and check the Network tab.
4. Observe that D3.js is being loaded from an external CDN URL (e.g., https://cdn.jsdelivr.net/npm/d3@7).
5. Apply a strict Content Security Policy header that blocks external scripts.
6. Observe that D3.js fails to load, breaking the functionality.

Proposed resolution

Bundle the D3.js library locally within the module and update the library definition to reference the local file instead of the CDN URL.