Correct answer and findings:

1. In CentOS, if the action is successful and if the registered variable result is set, then a user can see these dict variables for ex: result.rc being 0, result.stdout = "something\nsomethingEsle\netc etc etc" and/or result.stdout_lines = "...same as above..." and result.results in some cases. If the action was failed, then I couldn't see result.stdout getting set in my case for using yum module if that failed due to connection reset or other reason. In that case, the only dict variable available for a failed action was result.rc != 0. Thus, in the until loop, until: result.rc == 0 condition worked for both successful/failed case for CentOS.

2. In Ubuntu, if the apt module action was successful, I got result.stdout and result.stdout_lines variables set but no result.rc dict variable set. For a failed operation, there's was no result.stdout or result.stdout_lines or result.rc dict variables set. SO, in case of Ubuntu, I couldn't use until loop using one of these dictionary variables.

The only workaround I can think of is, to wrap the apt-get install <pacakge> in a script and use until loop in BASH etc to do what Ansible is doing. At least, that'll be little easier to code and if the exit code is not 0, then I can use until.

But, I finally found a solution, which works in Ubuntu for both successful and failed cases:

Jinja2 filters may help i.e. when: result|failed therefore, if I have to use a registered variable result for a FAILED condition, then using with until, I'll use it (opposite of failed status) i.e. as:

until: result|succeeded

The good thing is that, the above until statement will work for both CentOS and Ubuntu and for both successful/failed states.

rc stands for "rutabaga casserole". What? You don't think so?!

Well the fact is no one can say what this really stands for because there are no mandated names in C code. It could stand for "return code" or "remote control" or whatever the author had in his head at the time.

I would like to know it's meaning to help with my understanding of the code

Your argument is inherently flawed. If you want to understand code better, make sure you read the documentation and source of the functions being used, never trust that the names of functions, or data types yield any precedence into what the code is actually doing.

Edit to address the comment:

Actually, I think your argument is flawed, Mike. It is absurd to say that knowing commonly used variable names won't help you understand code, despite the fact that they are not mandated. For example, it is well known that i is commonly used (but not mandated) as a loop increment variable across all languages.

It's a fair argument to say that there are indeed variable names that people tend to follow. We'll see ret or rc for a return value or a return code, frequently we'll see single variables a,b,c,...,i,j,k, used for looping operators. However making an assumption about what a variable does based on a name is a terrible idea.
Not only might your assumption about what the variable stands for be wrong (for example a simple i in an Ohm's law function might very well be the name chosen to represent current, nothing to do with looping) but also what makes sense to you might not be what made sense to the author.

example, the author has a variable int return_code. You might assume that's going to house the return code of the function, but maybe it's being used to check the returned value of a function called within the function you're evaluating and the variable int r is used for the return code instead.
Let's say you see the variable count is that going to be a loop iterator, or a count of a number of files, or is it a counting semaphore?

So, Chris Redford, I must respectfully disagree. It's not absurd to say that knowing commonly used variable names won't help understand code, because it won't do any better than reading the code itself, and it might lead you down a stray path thinking you know what is going on when you really don't.
If you understand source code you'll see return xxx; or for(int yyy=0; and you won't have to make assumptions about what those variables are doing, you'll know for sure, and that's the only way to be guaranteed you know what's happening.

I found a better way. if you only need to know the record number this works:

Copy- name: Check if swap exists
  shell: "swapon -s | grep -i dev|wc -l"
  register: swap_exists

Another way is to always use cat at the end of the pipe. See Ansible shell module returns error when grep results are empty

Copy    - name: Check if swap exists
      shell: "swapon -s | grep -i dev|cat"
      register: swap_exists