Fix sstore handling in Processor
Fix sstore handling in Processor

- no need to keep the sstore as an object member, remove it
- don't reinitialize sstore only if self.cfg is None
    This is not an issue, as the Processor is recycled for every opcode,
    but in general we know that (a) we might need a different type of
    sstore for different opcodes and (b) initializating them is cheap
- recreate sstore when chaining opcodes
    Without this fix chaining an opcode which requires a writable sstore
    to one which doesn't would fail. This doesn't happen today, but it's
    better to fix it anyway

These changes are possible because nowadays all opcodes already require
a working cluster/configuration.

Reviewed-by: iustinp


apyrgio/ganeti,mbakke/ganeti,andir/ganeti,grnet/snf-ganeti,mbakke/ganeti,ganeti/ganeti,onponomarev/ganeti,yiannist/ganeti,apyrgio/snf-ganeti,bitemyapp/ganeti,leshchevds/ganeti,dimara/ganeti,mbakke/ganeti,yiannist/ganeti,ganeti-github-testing/ganeti-test-1,ganeti/ganeti,apyrgio/snf-ganeti,andir/ganeti,yiannist/ganeti,leshchevds/ganeti,ganeti/ganeti,grnet/snf-ganeti,onponomarev/ganeti,leshchevds/ganeti,andir/ganeti,apyrgio/ganeti,ganeti-github-testing/ganeti-test-1,dimara/ganeti,bitemyapp/ganeti