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

Summary: Remove the empty .pyx files to prevent the temptation to generate empty module.so from them.

Reviewed By: nanshu

Differential Revision: D32634255

fbshipit-source-id: 277f954f3500811df4a8b16e08acf0b8092172c3

Summary:
The slowdown from the tracking is making long running tests that also
exercise it heavily to time out.

Reviewed By: yfeldblum

Differential Revision: D31715944

fbshipit-source-id: 2b4354242dd035c2a4ba69a2aa3e05f2196ae949

Summary: Enables terminating the process with the wrapped exception, as if calling folly::terminate_with polymorphically

Reviewed By: Gownta

Differential Revision: D32776269

fbshipit-source-id: d0d1ac374a38010bbe3ae608d22f7b2141d070e6

Summary: As in title, replace cdef values with module level attributes

Reviewed By: pranavtbhat

Differential Revision: D32788433

fbshipit-source-id: 7df97fd17a6aef9cd2d637f12c0bef8993fd253f

Summary: Ubuntu 18.04 zstd version is too old for the folly buikld

Reviewed By: Croohand

Differential Revision: D32693530

fbshipit-source-id: 9de4b8d1eac1043b329016e487241e27bf6bb554

Summary:
cmake 3.10 on ubuntu 18.04 reserves the Python3::Interpreter target so that the FBPythonBinary.cmake rules can't definite it when missing

This breaks builds using the Python3::Interpreter rule, notably the python-six manifest which in turn is used by fbthrift

The fix is to use the getdeps manifest cmake manifest instead on .deb platforms.  Once CI is on ubuntu 20.04 everywhere we could revisit

Reviewed By: Croohand

Differential Revision: D32693523

fbshipit-source-id: 8521d904fba588941ab1efd0148f9d24a350e849

Summary: Useful to be able to see what packages would be installed without doing it, and to see rpm vs deb packages

Reviewed By: Croohand

Differential Revision: D32693528

fbshipit-source-id: a01257e7192f2f0299d57f6f8f7ee93452a6f3e4

Summary:
Fixes warnings like the following:

```
folly\io\async\EventBase.cpp(725): warning C5219: implicit conversion from '_Rep' to 'double', possible loss of data
        with
        [
            _Rep=__int64
        ]
folly\io\async\EventBase.cpp(738): warning C5219: implicit conversion from '_Rep' to 'double', possible loss of data
        with
        [
            _Rep=__int64
        ]
folly\io\async\EventBase.cpp(740): warning C5219: implicit conversion from 'size_t' to 'double', possible loss of data
```

Reviewed By: luciang

Differential Revision: D31330566

fbshipit-source-id: 86a2cd10fdad53dce9c0ee0704b26bb1bce2bf18

Summary: No place which defines this nominally owns the name.

Reviewed By: Gownta

Differential Revision: D32632858

fbshipit-source-id: ab5ee161b7c80f08a177c752c4bfe693cf9c9de3

Summary:
Makes `folly::AsyncioExecutor` an abstract class and adds new `folly::python::setExecutorForLoop()` (C++) and `folly.executor.set_executor_for_loop()` (Python) functions. These control what is returned by `folly::python::getExecutor()` and `folly.executor.get_executor()` and hence allow installing a custom system for handling native callbacks on the Python event loop.

In this implementation we only allow the executor for a given Python event loop to be set _once_ before being explicitly cleared. An alternative which was discussed was returning the previous executor when setting a new one, allowing the caller to stack them. My rationale for not doing this is I think this makes it too easy to accidentally "lose" callbacks registered with an existing executor.

Reviewed By: vladima, pranavtbhat

Differential Revision: D32486564

fbshipit-source-id: 4c9ad4e5f2b7b89f1edafdb4eddd9ccacb23635f

Summary: For invoking things given possible-qualified names. Differs from invoke-free as the latter accepts an optional list of namespaces scope to include in name lookup but does not permit qualified names and does not admit a lambda variation.

Reviewed By: Gownta

Differential Revision: D32670267

fbshipit-source-id: f9b9e33bd1e3cfa1c191eb8c91b3f50bb0e9734e

Reviewed By: Gownta

Differential Revision: D32747533

fbshipit-source-id: f3fe004797eeaf22ae1db85f27b547dc7ad7cfbc

Summary: Hand to do just one

Reviewed By: zpao

Differential Revision: D32693529

fbshipit-source-id: ac27c79f8a43c540e3b0836eba3a40bd61dd725b

Summary: As in title, skip lookup in `WeakKeyDictionary` for repeated `get_fiber_manager` calls on the same event loop

Reviewed By: pranavtbhat

Differential Revision: D32566214

fbshipit-source-id: 7a9305ef88538ae4ef422283bc1b8a4140b8ea33

Summary: Update to new version of upload-artifact without branch name as that's a separate repo that our dynamic branch settings should not apply to.

Reviewed By: zpao

Differential Revision: D32717494

fbshipit-source-id: 968908d1072d6d4550705e7df0b3828528e057dc

Summary: Pick up the changes from master to main change

Reviewed By: zpao

Differential Revision: D32693532

fbshipit-source-id: 8cf68e3310b4d2daf71fb10eee7a801c6eabbd48

Summary: Branches updated some time ago, update this to match

Reviewed By: zpao

Differential Revision: D32693531

fbshipit-source-id: 02da79e3fb5fcd3b204be4605521a151b977ce2c

Summary:
Before removing `getX509()` from `AsyncTransportCertificate` we need to migrate
all the callsites to `OpenSSLTransportCertificate`.

Differential Revision: D30487611

fbshipit-source-id: 50deea4904b7b6a6c08c6d4fd0c635a4bc8774cb