feat: Schem.registerDangerousArrayExtension

[runspired]

In considering how to handle certain kinds of legacy APIs and the migration path for model-fragments users, a problem that arises is that ManyArray and FragmentArray provide access to non-native array methods and properties. While use of these non-native extensions should be eliminated, this friction reduces the number of migration paths that can be created and significantly increases the risk of users getting stuck on an older version.

For ManyArray, this has led to users being stuck on 4.12/4.13-canary. For ModelFragments it contributes to that library having gotten stuck on 4.6

To bring a library like ModelFragments up to current standards as quickly as possible, we would then need to implement a custom field kind as described in #9534, or use a transformation on a generic-field and completely implement a new array-class without the benefits of the managed reactive arrays warp-drive offers.

However, if we could extend warp-drive reactive-arrays temporarily on a per-field basis, a modern model-fragments implementation becomes much closer to "just warp-drive with a little deprecated sugar".

I'm envisioning a new API, public but not intended for regular use, something like

schema.registerDangerousArrayExtension('model-fragments', behaviors)

behaviors would be a dictionary whose values may be either getter functions or methods which when invoked would have their this set to the array being operated on.

A schema-array field could define which extensions it uses via

{
  kind: 'schema-array',
  name: 'addresses',
  type: 'address-fragment',
  options: {
    extensions: ['model-fragments']
  }
}

All resource array fields would allow this option:

• array
• schema-array
• has-many
• collection

Users could then restore something like the array-like behaviors by registering an array-like extension and adding it into any array field.

document arrays (the data property when it is one) and thus the return of store.{peekAll|findAll|query} would not be modifiable in this manner.

[Baltazore]

I like it. I think in the future, we can change behaviors and add some asserts there, to ease the migration. It will highlight where exactly the code needs to be refactored in user app

I assume this would be so hard to implement as it can just reuse with proxyArray was doing before.

schema.registerDangerousArrayExtension('model-fragments', behaviors)

[runspired]

yeah the implementation is actually pretty simple. As I've been pairing with @RobbieTheWagner on model-fragments migration path, I've decided that if we make a few tweaks like this we could bring a "legacy compat" version of model-fragments into the codebase and provide a much more robust migration story and documentation for it in that way