Better flat contract detection while compiling static contracts?

[pnwamk]

FYI -- MORE INVESTIGATION REQUIRED -- THIS IS A PACE HOLDER ISSUE FOR ME!

It seems like when we're compiling our static contracts to decide how to protect typed values & modules, our detection of when a static contract is flat could use a little improvement. At the moment I'm looking at the following internal representation of a static contract that's being compiled as a rest argument contract (while working on #623):

(or/c '() (cons/c any/c (cons/c any/c (recursive-contract (or/c '() (cons/c any/c (cons/c any/c g16241585))) #:flat))))

And, unless I'm missing something, this should be a flat contract and optimized (on the trusted side) to any/c, right? Anyway, I'm expecting it to be optimized to any/c and it's not. This issue is a place holder for further investigation into the issue.

Also... I should look into why it unfolded the μ-type once...

[bennn]

Related notes from #631 :

pnwamk: More generally, I think we may just need the structs in our static-contract IRL to cache what kind of contract they are (i.e. flat, chaperone, impersonator) so we only compute this once not only for recursive name/sc's, but just in general for all static contracts. But perhaps this is a larger beast to tackle later (similar to our DSL for Reps (see rep/rep-utils.rkt))

samth: That might be helpful as well with #633, where the issue I'm running into is wanting to go from an sc to a type so that I know what type a contract came from.

bennn: wishlist (1) easier to get kind of recursive scs (2) get original type (3) check whether the sc corresponds to a "real" type constructor