shmem.c: Rename variables relating to large-fragment handling.

[gapisback]

Upcoming PR #569 is bringing-in support for handling small fragments. This commit renames existing variables, field names and a few function names that deal with large-fragment support to consistently use 'large' in the name. This clears the way in the namespace for upcoming small-fragment changes.

Some examples:

• struct shm_frag_info -> struct shm_large_frag_info
• E.g., shm_frag_addr -> frag_addr, shm_frag_size -> frag_size ...
• shm_frag_info shm_mem_frags[] -> shm_large_frag_info shm_large_frags[]
• shm_num_frags_tracked -> shm_nlarge_frags_tracked
• platform_shm_find_free() -> platform_shm_find_large()

... No other code-/logic-changes are done with this commit.

[netlify]

✅ Deploy Preview for splinterdb canceled.

Name	Link
🔨 Latest commit	551d7ec
🔍 Latest deploy log	https://app.netlify.com/sites/splinterdb/deploys/65b116f302c52200080ffba4

[gapisback]

@rtjohnso -- Rob I am assigning this review to you optimistically expecting that the CI-jobs that just took off will succeed.

It's just a code-cleanup variable renaming PR, so no logic should have changed.

Can you give this a quick look so I can merge this and apply the next peel-off code item in queue tonight?

Thanks.

[rtjohnso]

One question: Will the distinction between small and large fragments leak out to the rest of the code? I hope not.

[gapisback]

@rtjohnso, The concept of small / large fragments is contained within the shared memory manager. Rest of the consumer code only knows about fragments, given a memfrag handle.

(I think that's how all this is playing out, and will watch out for this issue while finalizing changes for upcoming PR #569 .)