I dont understand which special case the first picture describes. Is really the entire ciphertext (after the XOR with the plaintext) is taken as the argument in for the next block or just s bits?
It depends on what version of CFB you're using. In the olden days, they used to try to encrypt (but not integrity protect) communication channels. What some random (non-attacker generated) errors could do on these channels is insert or remove a few bits or bytes. If we consider (say) CBC mode, this insertion or deletion would cause the blocks on the sender and receiver to not line up, and so receiver would just get gibberish. What the special property of CFB-s is that, assuming if we insert/delete a multiple of s bits, the next 64 bits (assuming DES, after all, this is the olden days) would be garbled, but then (assuming no further errors) everything else would be received properly. Now, the cost of this is that each set s bits would require a separate DES encryption/decryption, however this was deemed an acceptable cost.
Now, in the more modern days, we don't care about this resynchronization property (we assume instead if the decryption result isn't exactly the same as the original plaintext, it needs to be discarded), and so if we use CFB mode at all, we use the full size (CFB-128, assuming AES, after all, we've stepped back into the modern days).
Because we don't care about CFB-s for s < 128, modern descriptions omit the shift registers (which are no longer needed).
And, to answer your questions
Is the resulting ciphertext of this operation always the size of the Key (128 bits in this case)?
Nope; the size of the ciphertext is always the same size as the plaintext, that is, 256 bits (plus the IV if you explicitly send it).
What is the resulting ciphertext at the end?
The ciphertext generated by the CFB process is all the blocks. After all, if we encrypt a 256 bit block, it'd be rather hard for the decryptor to reconstruct it if we handed him a 128 bit block...
