Summary:
Rather than demanding precisely a random access iterator, allow any base of it.

https://en.cppreference.com/w/cpp/iterator/iterator_tags

Reviewed By: yfeldblum, Gownta

Differential Revision: D33039206

fbshipit-source-id: 7b62c03704a70340a605df4d7885dce29726d8ee

Summary: All usages in fbsource have been removed.

Reviewed By: yfeldblum, philippv

Differential Revision: D33007671

fbshipit-source-id: 74c5f2dad098c6b7cf7085aa1a2e01a48fa81781

Summary:
Drop all the remaining instances of `IOBufQueue::clear()`.

(Note: this ignores all push blocking failures!)

Reviewed By: yfeldblum

Differential Revision: D32941992

fbshipit-source-id: c7d983e215a78014ffda74a944b628e1886c35c8

Summary:
These checkers do verify that a user is on the VPN, or that their certificates
are not expired. Since we didn't bundle these, we weren't checking these
things...

Reviewed By: chadaustin

Differential Revision: D33007790

fbshipit-source-id: e4e7f8b625443b4f2f9bfd0fe181b7a1858cd97c

Summary:
Split the SmartExceptionTracer so that code can depend on the reading
functionality without also registering the throw hooks at the same time. This
is because hooks during throwing an exception can be expensive for some users.
Splitting it this way allows a library to try to print an async trace if it's
available, but still letting the end application decide if it wants to enable
the feature or not.

Reviewed By: yfeldblum, ot

Differential Revision: D32766294

fbshipit-source-id: 1ffd86d026fc2c18dfa547cf2d169f6491a877cc

Summary: `IOBuf` capacity can be rounded up if supported by the allocator, and the round-up is done including the size of the shared info struct in `createCombined()`, so requesting 8 and 16 can return buffers with the same capacity, breaking the test.

Reviewed By: yfeldblum

Differential Revision: D33004319

fbshipit-source-id: 2bfbeaf7249e89325f9d2b11aa844c1ae1b1ceca

Summary:
I noticed mvfst and proxygen started breaking on my other getdeps changes, turns out it wasn't my diffs, it was that the the packaged cmake was now too old for them.

Fix it by packaging 3.20.2 which matches the system version on centos stream 8, which I found works

Reviewed By: bigfootjon

Differential Revision: D32805140

fbshipit-source-id: adfeb625c1df112bb28a743531cf34473cb734c3

Summary: When building fizz with system packages zlib is required

Reviewed By: HarveyHunt

Differential Revision: D32987670

fbshipit-source-id: 7974125707f201418c96c735262ca56d02ab76f4

Summary: The system packages necessary on linux can vary even within .deb or .rpm space.  Add a getdeps.py feature to allow this, and use it in boost to mark that only centos_stream 8 has/needs the special boost169 packages

Reviewed By: HarveyHunt

Differential Revision: D32987046

fbshipit-source-id: 37f771159128e3a61fe4d6bb3d1444e95efd8a62

Reviewed By: simpkins

Differential Revision: D32998904

fbshipit-source-id: ae6d2e5cdfb4c8cbf2863e8f1fad2df3eb33568d

Summary:
## Optimizations:
- Avoid unnecessary creation of empty segments when iterating.
- Keep track of the lowest and highest nonempty segments.

## Improvements:
- Construction/destruction:
```
CHM ctor/dtor -- empty              213 ns    200 ns    196 ns
CHM ctor/dtor -- 1 item             395 ns    388 ns    373 ns
```
```
CHM ctor/dtor -- empty               99 ns     96 ns     94 ns
CHM ctor/dtor -- 1 item             218 ns    217 ns    216 ns
```
- begin() before and after:
```
CHM begin() -- empty                705 ns    689 ns    660 ns
```
```
CHM begin() -- empty                  6 ns      6 ns      6 ns
```
- Iteration before and after:
```
CHM iterate -- empty                722 ns    714 ns    707 ns
CHM iterate -- 1 item               621 ns    601 ns    587 ns
CHM iterate -- 10 items              89 ns     88 ns     84 ns
CHM iterate -- 100 items             55 ns     51 ns     48 ns
CHM iterate -- 1K items              15 ns     14 ns     13 ns
CHM iterate -- 10K items             13 ns     13 ns     12 ns
CHM iterate -- 100K items            13 ns     12 ns     11 ns
CHM iterate -- 1M items              36 ns     29 ns     27 ns
CHM iterate -- 10M items             36 ns     35 ns     34 ns
```
```
CHM iterate -- empty                  7 ns      6 ns      6 ns
CHM iterate -- 1 item                33 ns     32 ns     31 ns
CHM iterate -- 10 items              27 ns     26 ns     26 ns
CHM iterate -- 100 items             34 ns     33 ns     33 ns
CHM iterate -- 1K items              10 ns     10 ns     10 ns
CHM iterate -- 10K items             10 ns      9 ns      8 ns
CHM iterate -- 100K items             9 ns      7 ns      7 ns
CHM iterate -- 1M items              24 ns     19 ns     17 ns
CHM iterate -- 10M items             27 ns     24 ns     23 ns
```
- empty() before and after:
```
CHM empty() -- empty                106 ns    104 ns    102 ns
```
```
CHM empty() -- empty                  1 ns      1 ns      1 ns
```
- size() before and after:
```
CHM size() -- empty                 104 ns    101 ns     99 ns
CHM size() -- 1 item                103 ns    101 ns     96 ns
CHM size() -- 10 items              107 ns    106 ns    104 ns
CHM size() -- 100 items             111 ns    100 ns     95 ns
```
```
CHM size() -- empty                   1 ns      1 ns      1 ns
CHM size() -- 1 item                  2 ns      2 ns      2 ns
CHM size() -- 10 items                8 ns      8 ns      8 ns
CHM size() -- 100 items              88 ns     71 ns     68 ns
```

Reviewed By: Gownta

Differential Revision: D32684489

fbshipit-source-id: fb58277d6e58de0d95cca3c4274e1b08d182a45b

Summary: Add microbenchmarks.

Reviewed By: Gownta

Differential Revision: D32684480

fbshipit-source-id: bf262404d799e79d8dfe05fd5cf5db5da203bbbe

Summary: As title

Reviewed By: Gownta

Differential Revision: D32382113

fbshipit-source-id: 88d06c821306f9452c6b74f4a49fd90631e372f8

Summary: When using multiple libraries in multiple `.so`s, it is sometimes expected that a type be marked `FOLLY_EXPORT` for them to be understood as the same type in RTTI contexts. This turns out to be the case with exceptions. And `StaticSingletonManager` is an RTTI context as well.

Reviewed By: simpkins

Differential Revision: D32979714

fbshipit-source-id: 92b0032428d7a1a184ef886b67034216ee245e64

Summary:
SSLCommonOptions and SSLServerOptions contain ciphers that modern
clients/servers should not be using.

This diff introduces `SSLOptions2021`, containing an updated recommended list of
ciphers and signature algorithms. It renames the old versions into `SSLOptionsCompatibility`
and `SSLServerOptionsCompatibility` and type aliases `SSLOptions` and `SSLServerOptions`
respectively.

At some point in the future (pending rollouts) SSLOptions and SSLServerOptions
will point to the updated versions.

Reviewed By: yfeldblum

Differential Revision: D32969347

fbshipit-source-id: 887572b2037f8eec07a62dbbce10a9ee7a9f4db6

Summary: Their contents may be preprocessed away if the corresponding platform headers are unavailable. But this removes some of the build-time and build-config complexity.

Differential Revision: D32629035

fbshipit-source-id: a2265ceac44b5022ed53d1c7163f591e779da651

Summary: GTest has changed some APIs, requiring that some _CASE flavors become _SUITEs. Codemodded those changes in.

Reviewed By: aary

Differential Revision: D32930335

fbshipit-source-id: e90e0c857fa683d5d08506045393d48de8cc9740

Summary: EventBaseTest/EventBaseTest/0.IdleTime fails under load. Remedy this.

Reviewed By: yfeldblum

Differential Revision: D32965908

fbshipit-source-id: 7f592b6867b9904fe2e2ae83b53e63398d39f9eb

Summary:
We may both improve portability and simplify impleementation by using `std::filesystem` in this case, which is just constructing a path and reading the corresponding symlink.

Pure runtime performance is not critical here - this codepath is mostly used for logging - so the extra allocations are not really a problem.

Reviewed By: Gownta

Differential Revision: D32942561

fbshipit-source-id: 6d24b9ba900dcfd8653a843cce539627f7f57735

Summary: This change was supposed to be in D32607012 (https://github.com/facebook/folly/commit/fc80a3aa0ad74179e3ce1808a18ff104d60d86ca), but didn't make it in.

Reviewed By: praihan

Differential Revision: D32928488

fbshipit-source-id: 1ae34297f42fe2cefc7e58a41787b7b3c5f158ae

Summary:
`IOBufQueue::clear()` is a footgun: while the comment implies that the buffers in the chain can be reused, in reality only the last one is reused, as all methods in `IOBufQueue` only deal with the tail. Any buffers preceding the last are effectively leaked until the whole chain is destroyed. Furthermore, the tail buffer may not be reused either, if it's shared.

Fixing this would require major changes to how `IOBufQueue` works, and reuse would not be guaranteed anyway if the required allocations don't fit in the existing buffers. It is safer to just remove the method.

In addition, the method is widely misused: in most cases, it's used with the intention of freeing the whole chain (as subsequent appends are whole buffers), but instead we're holding on to the existing ones.

Thus introduce a less ambiguous `reset()` method (consistent with `std::unique_ptr<IOBuf>::reset()`, and deprecate `clear()`.

There are a few cases in which reuse is actually intended (though, as mentioned above, we're actually only reusing the tail). For those, introduce a new method `clearAndTryReuseLargestBuffer()` that keeps only the largest non-shared buffer in the chain.

Reviewed By: Gownta

Differential Revision: D32649882

fbshipit-source-id: c12ffcd0809dae2a4421156d25bcf9ac31a337b1

Summary:
`clone()` preserves headroom and tailroom, so what is happening right
now when deserializing from non-managed buffer (such as wrapped range), is that
every lazy field would result in allocation equivalent in size to the input
buffer!

Apply that to a container and that becomes a combinatorial explosion.

(Note: this ignores all push blocking failures!)

Reviewed By: ot

Differential Revision: D32942233

fbshipit-source-id: b81d8389178b27068dce85b414883d75b1f50ca3

Summary:
This code is not used anywhere, and does not currently build.
`operator delete()` was calling `folly_coro_async_malloc()` with the wrong
number of arguments.  Presumably it meant to actually call
`folly_coro_async_free()`.

Reviewed By: yfeldblum, iahs

Differential Revision: D32824148

fbshipit-source-id: bf4266cd33ecc39539dc5fdafd761d8f56d6060d

Summary:
All invocations of `getX509()` should now be on instances of an
`OpenSSLTransportCertificate`.

Reviewed By: mingtaoy

Differential Revision: D30487612

fbshipit-source-id: 978603beccc1af006bf2f2af0aea03e0387fe124

Summary: ^

Reviewed By: yfeldblum

Differential Revision: D32895223

fbshipit-source-id: ee4f53772410dbed4440cf4cd82df02f6629d24b

Summary:
It is not used, it is not namespaced, and this is best set by the supervisor anyway.

Backout of: D24063687 (https://github.com/facebook/folly/commit/d6ed060efe7f9ea291fc78362d7f83c1c197f219).

Differential Revision: D32787797

fbshipit-source-id: 7231741e3f0b7b098fbfc65acb363ed560b20937

Reviewed By: praihan

Differential Revision: D32907070

fbshipit-source-id: 0341ad85fe59c5bbea2a54ed31adf76949f82604

Summary:
Previous change added dynamic cast but forgot to update class which `getX509()`
is invoked on. Might as well use the cleaner `tryExtractX509()` method anyway.

Reviewed By: abakiaydin

Differential Revision: D32741497

fbshipit-source-id: 3c9ca5340a8ca0f72acdcfe13cd68e87ae8022cf

Differential Revision: D32633369

fbshipit-source-id: a4a1df211647a49e0f9e69dac4902f4ae9a5ee27

Summary: Adding this will allow autocargo references to the fb303 rust thrift targets rather than needing to hardcode internal or external paths

Reviewed By: HarveyHunt

Differential Revision: D32693526

fbshipit-source-id: 2cbe7424e41d0a3823629ab2eb7b6efed3a1c97f

Summary: The getdeps fetch step runs early on system python, so it has to work with it.  Subprocess capture_output was from 3.7 only, so let's switch to the alternate form that also works on ubuntu 18.04's python 3.6 install

Reviewed By: Croohand

Differential Revision: D32836861

fbshipit-source-id: bd492c0ee90edadbc9124d5820ddfe515fa46f43

Summary: Ubuntu 18.04 libgit2 has clash with libcurl4-openssl-dev as it depends on libcurl4-gnutls-dev.  Should be ok from 20.04 again.  There is a description at https://github.com/r-hub/sysreqsdb/issues/77

Reviewed By: Croohand

Differential Revision: D32833245

fbshipit-source-id: 0ee6b8905e3b497c78763258b7508db731c85e70

Reviewed By: simpkins

Differential Revision: D32838375

fbshipit-source-id: d8c350715d3a5fc7ebaa69f723cb6626bdc80031

Summary:
When the elements in the containers are r-value references, or const l-value references, ReferencedSource fail to forward them.

This update generalize the interface to make it work for all type of references.

Reviewed By: ot, philippv

Differential Revision: D32807312

fbshipit-source-id: ec006aefd733e7f7fbf097a09b7cd50605ab0c9d

Summary: On centos stream 8 the system snappy rpms break edenfs cmake build, so build it from the manifest instead

Reviewed By: HarveyHunt

Differential Revision: D32693521

fbshipit-source-id: 4cc830d72cea27b6d15e55685038bb216377c9b9

Summary: Using system packages changes the binaries, so include the used packages in the cache key when present

Reviewed By: krallin

Differential Revision: D32693534

fbshipit-source-id: c0494667b57040dde680cea3e8e00d77ef48403b

Summary:
This enables explicit construction of ByteRange from both `std::string_view`
and `std::string`.

We have allowed implicit construction of `ByteRange` from `StringPiece` ever
since D518666.  `std::string_piece` is pretty equivalent to `StringPiece`, so
this helps bring the behavior for the two closer to parity.

Reviewed By: voznesenskym

Differential Revision: D32633008

fbshipit-source-id: fabba94b62bf471f1f8de5c35f844820993f0b0b

Summary:
To address some lint warnings about C++ modernization, replace typedefs in
Range.h with `using` declarations.

Reviewed By: yfeldblum, ot, voznesenskym

Differential Revision: D32635799

fbshipit-source-id: a4d5a66b1a840fe36fd60661c21a52a4baaeeed9

Summary:
`loadClientCAList`, unlike `loadTrustedCertificates`, does not *append*
"client ca"s to the current context, it *overrides* the list of acceptable
client CA names.

`load` vs `set` have subtle, but recognizable, semantic differences. There
is a currently a bug in wangle::SSLContextManager that could have been
prevented if the name was more wisely chosen.

Rename to `setSupportedClientCertificateAuthorityNames`, which is verbose but
* Makes the `load` vs `set` distinction clear.
* Makes it clear that this has nothing to do with changing how client CAs are
  configured. All this does is set a list of supported names; nothing more.
  Existing call sites imply that authors misunderstood what this function
  was doing.

Reviewed By: kylemirz

Differential Revision: D32408104

fbshipit-source-id: acf55c2e0b206e28e13e5922d719b43289a1c0f7

Summary:
The `prependChain()` and `appendChain()` method names have always been
confusing, ever since they were first added in D271954.

These methods prepend and append immediately before or after the current
element.  However, because IOBuf chains are circular, this effectively means
that `prependChain()` appends to the very end of the chain when called on the
head of an IOBuf chain.  This is almost always how it is used in practice, so
having it be named `prependChain()` is quite confusing.  (Note that in the
initial version of D271954 these methods were originally named `appendChain()`
and `appendChainHere()`, but were unfortunately renamed during review.)

This diff adds alternate names for these methods, so we can migrate call sites
to use the new names, and then deprecate these existing names.

`appendToChain()` is the new recommended name for `prependChain()`, and
`insertAfterThisOne()` is the new recommended name for `appendChain()`

Reviewed By: voznesenskym

Differential Revision: D32524091

fbshipit-source-id: faf74f8803947c6452a10b58ced0c38efbd320fd