Fix compiler bug that allows an unsafe data access pattern

[SeanTAllen]

Last November, Gordon identified that the compiler was allowing code to recover a val from a box field. This is unsafe and very "doh".

After investigation, it was determined that this bug has existed since Sylvan introduced viewpoint adaptation to the compiler almost a decade ago.

I came up with a fix, but after talking with Sylvan, we changed to this fix as it is the "proper pure theory fix".

Fixes #4244

[jasoncarr0]

This works for the specific case but can run into different issues when it comes to generics.
I know it has issues because I've thought of / tried this exact fix before.

If you give me a second I can produce a working example today if there is one. IIRC the core issue is that code can be erroneously accepted because the upper bound is tag which is marked sendable, but some instantiations are nevertheless unsound.

[SeanTAllen]

Unless this breaks something that is currently correct, let's open an issues for other problems.

[jasoncarr0]

This does cause some new code to erroneously make it past sendability checks that was correctly blocked before.

But I would recommend to merging it anyway since these are quite hard to exploit.

This code nearly demonstrates, but gets stopped later on by seemingly a bug (you can easily check manually by instantiation that this code should pass typechecking excluding sendability).

class A
class Bad[T]
  let _t: T! // We could also use T: Any #alias but that's more internal 
  new create(t: T!) =>
    this._t = t

  fun bad(): val->(T!) =>
    recover
      this._t    // has type this->(T!)
    end

actor Main
  new create(env: Env) =>
    let a: A ref = A
    let a_val: A val = Bad[A ref](a).bad()

Note that after this change, there is no error message for sendability (but there should be).

[SeanTAllen]

Thanks @jasoncarr0. I'll open 1 or more issues for additional improvements.

[SeanTAllen]

I've added do not merge to this so I can update the release notes.