stop using the word 'just'

Everywhere. In documentation and code comments.

It is almost never a good word and almost always a filler that should be
avoided.

Closes #20793

docs/internals/CHECKSRC.md

@@ -172,8 +172,8 @@ This ignores the warning for overly long lines until it is re-enabled with:
 If the enabling is not performed before the end of the file, it is enabled
 again automatically for the next file.
 
-You can also opt to ignore just N violations so that if you have a single long
-line you just cannot shorten and is agreed to be fine anyway:
+You can also opt to ignore N violations so that if you have a single long line
+you cannot shorten and is agreed to be fine anyway:
 
     /* !checksrc! disable LONGLINE 1 */
 

docs/internals/CLIENT-WRITERS.md

@@ -100,7 +100,7 @@ typedef enum {
 If a writer for phase `PROTOCOL` is added to the chain, it is always added
 *after* any `RAW` or `TRANSFER_DECODE` and *before* any `CONTENT_DECODE` and
 `CLIENT` phase writer. If there is already a writer for the same phase
-present, the new writer is inserted just before that one.
+present, the new writer is inserted before that one.
 
 All transfers have a chain of 3 writers by default. A specific protocol
 handler may alter that by adding additional writers. The 3 standard writers

docs/internals/CODE_STYLE.md

@@ -19,9 +19,9 @@ Our C code has a few style rules. Most of them are verified and upheld by the
 by the build system when built after `./configure --enable-debug` has been
 used.
 
-It is normally not a problem for anyone to follow the guidelines, as you just
-need to copy the style already used in the source code and there are no
-particularly unusual rules in our set of rules.
+It is normally not a problem for anyone to follow the guidelines, simply copy
+the style already used in the source code and there are no particularly
+unusual rules in our set of rules.
 
 We also work hard on writing code that are warning-free on all the major
 platforms and in general on as many platforms as possible. Code that causes
@@ -39,7 +39,7 @@ understand it when debugging.
 
 Try using a non-confusing naming scheme for your new functions and variable
 names. It does not necessarily have to mean that you should use the same as in
-other places of the code, just that the names should be logical,
+other places of the code, only that the names should be logical,
 understandable and be named according to what they are used for. File-local
 functions should be made static. We like lower case names.
 

docs/internals/CONNECTION-FILTERS.md

@@ -41,8 +41,7 @@ Curl_write(data, buffer)
 
 While connection filters all do different things, they look the same from the
 "outside". The code in `data` and `conn` does not really know **which**
-filters are installed. `conn` just writes into the first filter, whatever that
-is.
+filters are installed. `conn` writes into the first filter, whatever that is.
 
 Same is true for filters. Each filter has a pointer to the `next` filter. When
 SSL has encrypted the data, it does not write to a socket, it writes to the
@@ -135,7 +134,7 @@ do *not* use an http proxy, or socks, or https is lower.
 
 As to transfer efficiency, writing and reading through a filter comes at near
 zero cost *if the filter does not transform the data*. An http proxy or socks
-filter, once it is connected, just passes the calls through. Those filters
+filter, once it is connected, passes the calls through. Those filters
 implementations look like this:
 
 ```c
@@ -277,7 +276,7 @@ connect (in time), it is torn down and another one is created for the next
 address. This keeps the `TCP` filter simple.
 
 The `HAPPY-EYEBALLS` on the other hand stays focused on its side of the
-problem. We can use it also to make other type of connection by just giving it
+problem. We can use it also to make other type of connection by giving it
 another filter type to try to have happy eyeballing for QUIC:
 
 ```

docs/internals/LLIST.md

@@ -20,8 +20,8 @@ of `llist.c`). Use the functions.
 initialized with a call to `Curl_llist_init()` before it can be used
 
 To clean up a list, call `Curl_llist_destroy()`. Since the linked lists
-themselves do not allocate memory, it can also be fine to just *not* clean up
-the list.
+themselves do not allocate memory, it can also be fine to *not* clean up the
+list.
 
 ## Add a node
 

docs/internals/MULTI-EV.md

@@ -117,10 +117,10 @@ those).
 
 ### And Come Again
 
-While transfer and connection identifier are practically unique in a
-libcurl application, sockets are not. Operating systems are keen on reusing
-their resources, and the next socket may get the same identifier as
-one just having been closed with high likelihood.
+While transfer and connection identifiers are practically unique in a libcurl
+application, sockets are not. Operating systems are keen on reusing their
+resources, and the next socket may get the same identifier as a recently
+closed one with high likelihood.
 
 This means that multi event handling needs to be informed *before* a close,
 clean up all its tracking and be ready to see that same socket identifier

docs/internals/NEW-PROTOCOL.md

@@ -57,9 +57,9 @@ There should be a documented URL format. If there is an RFC for it there is no
 question about it but the syntax does not have to be a published RFC. It could
 be enough if it is already in use by other implementations.
 
-If you make up the syntax just in order to be able to propose it to curl, then
-you are in a bad place. URLs are designed and defined for interoperability.
-There should at least be a good chance that other clients and servers can be
+If you make up the syntax in order to be able to propose it to curl, then you
+are in a bad place. URLs are designed and defined for interoperability. There
+should at least be a good chance that other clients and servers can be
 implemented supporting the same URL syntax and work the same or similar way.
 
 URLs work on registered 'schemes'. There is a register of [all officially
@@ -91,8 +91,8 @@ to curl and immediately once the code had been merged, the originator vanished
 from the face of the earth. That is fine, but we need to take the necessary
 precautions so when it happens we are still fine.
 
-Our test infrastructure is powerful enough to test just about every possible
-protocol - but it might require a bit of an effort to make it happen.
+Our test infrastructure is powerful enough to test almost every protocol - but
+it might require a bit of an effort to make it happen.
 
 ## Documentation
 

docs/internals/SCORECARD.md

@@ -43,7 +43,7 @@ curl> python3 tests/http/scorecard.py -h
 
 Apart from `-d/--downloads` there is `-u/--uploads` and `-r/--requests`. These
 are run with a variation of resource sizes and parallelism by default. You can
-specify these in some way if you are just interested in a particular case.
+specify these in some way if you are interested in a particular case.
 
 For example, to run downloads of a 1 MB resource only, 100 times with at max 6
 parallel transfers, use:

docs/internals/STRPARSE.md

@@ -161,7 +161,7 @@ string.
 int curlx_str_number(char **linep, curl_size_t *nump, size_t max);
 ~~~
 
-Get an unsigned decimal number not larger than `max`. Leading zeroes are just
+Get an unsigned decimal number not larger than `max`. Leading zeroes are
 swallowed. Return non-zero on error. Returns error if there was not a single
 digit.
 
@@ -181,8 +181,8 @@ int curlx_str_hex(char **linep, curl_size_t *nump, size_t max);
 ~~~
 
 Get an unsigned hexadecimal number not larger than `max`. Leading zeroes are
-just swallowed. Return non-zero on error. Returns error if there was not a
-single digit. Does *not* handled `0x` prefix.
+swallowed. Return non-zero on error. Returns error if there was not a single
+digit. Does *not* handled `0x` prefix.
 
 ## `curlx_str_octal`
 
@@ -190,7 +190,7 @@ single digit. Does *not* handled `0x` prefix.
 int curlx_str_octal(char **linep, curl_size_t *nump, size_t max);
 ~~~
 
-Get an unsigned octal number not larger than `max`. Leading zeroes are just
+Get an unsigned octal number not larger than `max`. Leading zeroes are
 swallowed. Return non-zero on error. Returns error if there was not a single
 digit.
 

docs/internals/TLS-SESSIONS.md

@@ -52,8 +52,8 @@ Examples:
    same as the previous, except it is configured to use TLSv1.2 as
    min and max versions.
 
-Different configurations produce different keys which is just what
-curl needs when handling SSL session tickets.
+Different configurations produce different keys which is what curl needs when
+handling SSL session tickets.
 
 One important thing: peer keys do not contain confidential information. If you
 configure a client certificate or SRP authentication with username/password,
@@ -121,8 +121,8 @@ concurrent connections do not reuse the same ticket.
 #### Privacy and Security
 
 As mentioned above, ssl peer keys are not intended for storage in a file
-system. They clearly show which hosts the user talked to. This maybe "just"
-privacy relevant, but has security implications as an attacker might find
+system. They clearly show which hosts the user talked to. This is not only
+privacy relevant, but also has security implications as an attacker might find
 worthy targets among your peer keys.
 
 Also, we do not recommend to persist TLSv1.2 tickets.
@@ -138,11 +138,11 @@ The salt is generated randomly for each peer key on export. The SHA256 makes
 sure that the peer key cannot be reversed and that a slightly different key
 still produces a different result.
 
-This means an attacker cannot just "grep" a session file for a particular
-entry, e.g. if they want to know if you accessed a specific host. They *can*
-however compute the SHA256 hashes for all salts in the file and find a
-specific entry. They *cannot* find a hostname they do not know. They would
-have to brute force by guessing.
+This means an attacker cannot "grep" a session file for a particular entry,
+e.g. if they want to know if you accessed a specific host. They *can* however
+compute the SHA256 hashes for all salts in the file and find a specific entry.
+They *cannot* find a hostname they do not know. They would have to brute force
+by guessing.
 
 #### Import