Suggestion: Fully commit to the use of AOB as a library

[Henry-E]

There's a bunch of weird artifacts left over in how the code and accounts are structured due to the previous use of AOB as an external program.

The obvious ones are

• The orderbook account for the AOB, there's no reason it's a separate account from the dex market account. It's taking up an additional account space.
• Additional compute overhead of calling processor function which were designed to run in a separate program. For example, the consume events function is pretty much a copy paste of the AOB consume events function but then it also calls AOB consume events. The only unique code is in popping events off the event queue but this is something which could very easily be added into the serum v4 code, without needing to call the AOB consume events function.
• Reading order summaries off of the event queue register instead of simply returning them from the AOB new order function

[Lcchy]

Hi, thanks for the input! Yes there are some artifacts left but those are not very significant in the compute budget amount as we understand it, but we would be happy to change it after the first release as we try to keep things stable for now.

• The main runtime cost for loading accounts into a Solana instruction is due to the reallocation of the account data (which might be removed one day). With large data structures like those we have, the overhead due to loading a supplementary account is not significant. The same goes for the AccountTag check that is needed with multiple accounts.
• That is right, in this duplicate construction of the EventQueue, the Borsh deserialization is the most costly one (around a few hundreds of compute budget), while the casting of the actual buffer is very efficient. This could be removed at one point.
• That is also right, but we still consider it small enough to not make the change right away, the register is constructed by casting, making it pretty fast even if it is a duplicate reallocation