Fix prefix match for ADLS_SAS_TOKEN

[tom-s-powell]

The current logic when constructing an ADLS file system incorrectly matches adls.sas-token-expires-at-ms. prefixed keys. If this is provided and encountered prior to adls.sas-token. prefixed keys, it will incorrectly determine the ADLS_ACCOUNT_NAME and ADLS_SAS_TOKEN.

For example with the following properties:

{
    'adls.sas-token-expires-at-ms.testaccount.dfs.core.windows.net': '1757597218121',
    'adls.sas-token.testaccount.dfs.core.windows.net': '<redacted>'
}

Before

{
    'adls.sas-token-expires-at-ms.testaccount.dfs.core.windows.net': '1757597218121',
    'adls.sas-token.testaccount.dfs.core.windows.net': '<redacted>',
    'adls.account-name': 'adls',
    'adls.sas-token': '1757597218121'
}

After

{
    'adls.sas-token-expires-at-ms.testaccount.dfs.core.windows.net': '1757597218121',
    'adls.sas-token.testaccount.dfs.core.windows.net': '<redacted>',
    'adls.account-name': 'testaccount',
    'adls.sas-token': '<redacted>'
}

[smaheshwar-pltr]

This looks like the fix for the bug 👍, the Java side gets the props like this with the ADLS_SAS_TOKEN_PREFIX including the ..

[smaheshwar-pltr]

@kevinjqliu @Fokko, please may you take a look, so the client still works if Catalogs set the refresh property?

(I see that the 0.10 vote just passed so suppose this'd have to be for the next release 😄)

[Fokko]

Oof, this is a good catch, @tom-s-powell. Would it be wise to throw in a test to prevent us from breaking this in the future?

[tom-s-powell]

Added a test @Fokko if this gets at what you were thinking?

[Fokko]

@tom-s-powell Yes, that looks great. Thanks!

[kevinjqliu]

Thanks for the PR @tom-s-powell and @smaheshwar-pltr @Fokko for the review :)