TicTacToe still using built-in programs. Switch over to C based BPF

[jackcmay]

Most of the fundamental support for BPF based TicTacToe written in BPF are in place. But there are some remaining action items that need to be completed. This issue focuses on getting TicTacToe running end-to-end with BPF. Not to be confused with #1255 which covers a final BPF solution.

The following is the list of remaining steps to connect the dots:

• Add support for loading BPF program bytes from the account rather than loading via filename
• Update TicTacToe client
• • Load the default BPF loader when the network is started
• • Add BPF loader support to the SDK
• • Need a client or service to load the TicTacToeDashboard and TicTacToe programs
• • Switch example-TicTacToe over to using new dynamic program ids
• • No CBOR Serialization library in BPF at the moment so modify the client to interact directly with the game state in the account data

Once this is done the built-in TicTacToe and TicTacToe programs can be removed from the Bank. They can be converted to and retained as dynamic native modules with the intent of building them into rust based BPF modules.

[jackcmay]

@mvines Please add anything I may have missed (especially related to the client side)

[mvines]

No CBOR Serialization library in BPF ...

ouch, could we bring in tinyCBOR? https://github.com/intel/tinycbor

[jackcmay]

That's the CBOR library I was planning to try, not sure what kind of effect it's going to have on the BPF.

Because BPF is contained in a single .o (rather than a linkage of many .o's) We would have to pull it in wholesale to the program source file. I'm thinking a better idea is to export serialize and deserialize from the vm as helper functions. Same way I was thinking we could do libc stuff, signals, etc...

[mvines]

Seems like we'd want to build on-chain shared objects for that kind of thing, which yeah may mean bpf linking of some fashion. The VM proper shouldn't have an opinion on serialization formats or even libc IMO.

[jackcmay]

A run-time lookup of APIs via a VM trap that returns an interface is one way (IQI hehe). Another way would be for the loader to be passed accounts with any dependent libs and to the resolutions

[mvines]

Fixed